Using an array type in the schema for an Ada interface to a postgresql database using gnatcoll_db2ada

Viewed 108

I've created a Postgresql database with a few tables and am fairly content with how they work. I've also written some Ada code to interface with and perform simple queries. This all running on Slackware 14.2 using GNAT 2020.

One of my table columns is of an array type, an array of BIGINT.

The problem I have is when I try to create the schema for my Ada using gnatcoll_db2ada.

The schema file ("all-schema.txt") includes the following line:

item_list | BIGINT[] | | | |

When I do

gnatcoll_db2ada -dbmodel all-schema.txt

I get

Error: unknown field type "BIGINT[]"
all-schema.txt:33 gnatcoll-sql-inspect.adb:1420
gnatcoll-sql-inspect.adb:1420

Is what I'm trying to do actually possible?

2 Answers

The documentation suggests that database fields of array types are not supported (i.e. they are not mentioned as being supported). From the document SQL: Database interface:

The type of the field is the SQL type ("INTEGER", "TEXT", "TIMESTAMP", "DATE", "DOUBLE PRECISION", "MONEY", "BOOLEAN", "TIME", "CHARACTER(1)"). Any maximal length can be specified for strings, not just 1 as in this example. The tool will automatically convert these to Ada when generating Ada code. A special type ("AUTOINCREMENT") is an integer that is automatically incremented according to available ids in the table. The exact type used will depend on the specific DBMS.

Note that while the scalar field type "BIGINT" is not mentioned in the documentation, it is mentioned in the source code (see gnatcoll-sql.ads).

If you really need support for the "BIGINT" array type, then a quick glance at the source code suggests that you can extend the GNATCOLL DB interface with new field types by

  • using the generic package GNATCOLL.SQL_Impl.Field_Types (see here) and
  • the creation of a new field mapping (i.e. a new concrete type based on GNATCOLL.SQL.Inspect.Field_Mapping, see here).

It seems that new field types are typically placed in package GNATCOLL.SQL_Fields (see here).

Note that I never did this myself, so I cannot tell how much effort it will be and whether this is really all that is needed; The exact requirements for implementing a new field type are (at the time of writing) not documented.

I suspected as much, having briefly looked at the source.

What I'll do is spin off the array into another table. This at least has helped clarify what I need to, and the array, to be fair, always felt a bit clunky. Thanks for the the comments.

Related