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
In the generated `CatalogImpl` subclasses the static fields representing
the schemas of the catalog typically don't need a fully qualified class
reference in the initializer expression, since the Java type is imported
already.
Additionally the Javadoc comment of the field representing the default
schema (if any) will now also include the schema's name (before it was
missing).
Fixes the Javadoc comment of the default catalog and schema singletons
generated into the `CatalogImpl` and `SchemaImpl` subclasses. For the
default catalog and schema the name was always empty.
In the generated `SchemaImpl` subclasses the static fields representing
the tables of the schema typically don't need a fully qualified class
reference in the initializer expression, since the Java type is imported
already.
The genereated `SchemaImpl` and `CatalogImpl` subclasses will only
declare methods like `getSchemas0()` and `getTables0()` when necessary.
I.e. when the number of returned definitions exceeds 500.
