In addition to runtime schema and table mapping,
`Settings#renderMapping` now also supports mapping of catalogs. This is
represented by the new `RenderMapping#catalogs`, which in turn can
contain mapping definitions for schemata and tables.
For backwards compatibility and for applications where no catalog
mapping is required, the old `RenderMapping#schemata` remains. Users are
expected to use _either_ of 'RenderMapping#catalogs` or
`RenderMapping#schemata`, but not both.
Instead of running a separate query to check if the table has any
identity column this is now being done with a `COUNT(*) FILTER (WHERE
is_identity = 'YES') OVER ()` expression.
The code generator will now generate a call to the new
`Internal#createQueue()` factory method instead of directly calling the
`QueueImpl` constructor.
The jOOQ code generator will now only map `COLUMNS.IS_IDENTITY` to
`ColumnDefinition#isIdentity()` if the table has a column for which
`COLUMNS.IS_IDENTITY` is `YES`. Otherwise it will continue to check if
the default value starts with `nextval`.
While `CURRENT_TIME` doesn't work in the CockroachDB release we
currently use in our integration testing, the necessary changes have
apparently already been integrated. This commit adjusts `CurrentTime`
accordingly so that it will work properly against releases which have
this built-in implemented.
By default (`Settings#renderParenthesisAroundSetOperationQueries =
false`) jOOQ will attempt to avoid rendering parenthesis pairs around
the queries combined with set operators (e.g. `UNION` or `UNION ALL`).
In situations where this causes problems, i.e. when the parenthesis pair
is required, the setting can be set to `true` in which case the
parenthesis pair will always be rendered around each of the combined
queries.
As of PostgreSQL 10.0 the column
`INFORMATION_SCHEMA.COLUMNS.IS_IDENTITY` can be used to determine
whether a column represents a table's identity column or not. This is
now used by jOOQ's code generator and for older releases it will
continue to check wheter the default value (i.e. using
`INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT`) starts with `NEXTVAL`.
The `DUAL` table will now be rendered as a `Name` rather than as the
plain string `dual`. This way it will also adhere to the name case
settings in the rendered SQL.
This new `fieldsFromSource()` method can be used when all or a subset of
the input field names exactly match the target table column names. The
load operation can then be executed without having to specify the fields
and will create rows with all matching fields (other fields are
ignored).
Since the fields are mapped by name this requires the input to specify
the field names. For CSV this means that there must be a header row,
otherwise using `fieldsFromSource()` will result in a runtime exception.
The way the schema mapping was implemented resulted in the schema
mapping always getting applied twice during the rendering. This was
problematic for regex based schema mappings using backreferences.
This commit changes the schema mapping logic so that
`SchemaMapping#map(Schema)` doesn't "recursively" map schemas. I.e. any
given schema is only mapped once.
When using the Sakila DB with the Docker image postgres:12.1 the
initialisation fails with:
ERROR: language "plpgsql" already exists
With PostgreSQL 8.4 (see [1]) and earlier it was only possible to
execute:
CREATE [ PROCEDURAL ] LANGUAGE name
Starting with PostgreSQL 9.0 (see [2]) it is possible to execute:
CREATE [ OR REPLACE ] [ PROCEDURAL ] LANGUAGE name
This commit makes the SQL script incompatible with PostgreSQL 8.4
and earlier.
[1] https://www.postgresql.org/docs/8.4/sql-createlanguage.html
[2] https://www.postgresql.org/docs/9.0/sql-createlanguage.html
