Array support

[Erikvv]

Add ability to define fields as arrays. This is only implemented for the driver pgx. This is the way to declare it:

model user (
	key id
	field pet_names string ( array, updatable )
)

The change does not introduce a syntax with brackets because the feature is probably used too rarely to warrant introducing new tokens. (in general I think the drawbacks of DSL's like DBX usually outweight the benefits vs expressing it in the host language, in this case Go).

An array in Go is always nullable, so there is no pointer to array if the field is nullable on the SQL side. The generated code takes care to distinguish between nil and an empty array.

When reviewing, please consider whether changes are in the right place. The codebase is unfamiliar to me and it has few comments to guide the developer. Making this change felt like a blind man touching an elephant.

This change exposes/introduces some shortcomings in the approach to generate code, but it is functional. It can work as a starting point to improve those.

A follow-up on this change would be to add a way to atomically append to an array.

Another addition would be support for length and dimensions. We can think of how to add these attributes while adhering to the rules and spirit of the current syntax. Postgres supports these attributes but does not enforce that the data conforms to them. Example idea:

model user (
	field my_array int (
		array(dimensions 2 length (3 2))
		updatable
	)
)

Change moved from https://review.dev.storj.io/c/storj/dbx/+/9297 to GitHub. Open feedback has been addressed.

Run tests using docker-compose run gotest

Change-Id: If773dc1c900b31dfe321d3d0172361b98c79451d

[egonelbre]

One of the drawbacks at the moment is that this will be included despite the actual implementation included. I'm not sure whether it ends up in the final binary when you are using only one backend (e.g. sqlite). However, it's not a critical issue per se.

[Erikvv]

Yes pgtype does end up in there even with sqlite. This is a drawback.

I could move this to a template file. Another approach would be make the sqlgen/sqlbundle aware of dialects and only include the requested ones.

It doesn't seem to get any easier to understand with either of those approaches.