…hange (refs liquibase#6885)

Adds the structural-model and change-object pieces needed for liquibase#6885's diff/
generate-changelog fix to round-trip a Postgres declarative-partitioning
specification through Liquibase. After this commit, the changelog XML form
`<createTable tableName="foo" partitionBy="RANGE (created_at)">` parses and
re-applies correctly; the snapshot side (reading partitionBy from a live
database via pg_partitioned_table / pg_get_partkeydef) lands in the next
commit.

Changes
-------
1. liquibase.structure.core.Table
   New `getPartitionBy()` / `setPartitionBy(String)` backed by the
   DatabaseObject attribute map, mirroring the existing `tablespace`
   accessor pattern. Documented as "verbatim pg_get_partkeydef output for
   declaratively-partitioned PostgreSQL tables". Null for non-partitioned
   tables and on databases that do not support declarative partitioning.

2. liquibase.change.core.CreateTableChange
   - New `@Setter private String partitionBy;` field with
     `@DatabaseChangeProperty(supportsDatabase = "postgresql")` getter so
     the XSD and YAML-emitter pick it up automatically.
   - `generateCreateTableStatement()` now threads `getPartitionBy()` onto
     the produced CreateTableStatement via the fluent setter introduced in
     the previous commit.
   - `getExcludedFieldFilters(ChecksumVersion)` now version-gates the
     `partitionBy` exclusion. For V8 and earlier, partitionBy is excluded
     from the checksum so pre-existing changesets (which never had this
     field) keep their stored checksums after upgrading. For V9+,
     partitionBy contributes to the checksum so changes to the partition
     spec are caught by validation. Pattern mirrors
     CreateViewChange.java:165 (added in 4.22.0 alongside the V8→V9 bump).

Tests
-----
New cases in CreateTableChangeTest:

  "partitionBy round-trips through setter/getter"
    Trivial setter/getter sanity.

  "generateStatements threads partitionBy onto the CreateTableStatement"
    A CreateTableChange with partitionBy="RANGE (test_date_int)" must
    surface that string on the produced CreateTableStatement (which is
    what the CreateTableGenerator added in the previous commit consumes).

  "getExcludedFieldFilters version-gating for partitionBy" — @unroll, 3
  sub-cases:
    V7: contains("partitionBy") == true   (excluded — smooth upgrade)
    V8: contains("partitionBy") == true   (excluded — smooth upgrade)
    V9: contains("partitionBy") == false  (included — validate changes)

All 62 CreateTableChangeTest cases pass; broader CreateTable* matcher
covers 122 tests, 0 failures.

Refs liquibase#6885

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…-generated changelog (fixes liquibase#6885)

Closes the user-visible bug from liquibase#6885. After this commit,
`liquibase generate-changelog` and `liquibase diff-changelog` against a
PostgreSQL database that contains declaratively-partitioned tables now
preserve the PARTITION BY clause in the generated <createTable> change set.
Pre-fix, the same command silently produced a plain CREATE TABLE; applying
the generated changelog to a target database produced a non-partitioned
heap copy of the source — a structural divergence not visible in the
changelog text itself.

Scope: parent-table PARTITION BY clause only. Child-partition
(`CREATE TABLE child PARTITION OF parent FOR VALUES ...`) enumeration via
pg_inherits / pg_get_expr(relpartbound) is deliberately out of scope for
this PR and remains as raw <sql> change sets — same as today's user
workaround. See the design discussion in the PR body for rationale.

Changes
-------
1. liquibase.snapshot.JdbcDatabaseSnapshot.queryPostgres
   + new private enrichPostgresqlTablesResult(...) method

   queryPostgres' existing extract(databaseMetaData.getTables(..., {"TABLE",
   "PARTITIONED TABLE"})) already pulled partitioned-table rows into the
   cache (pg_class.relkind = 'p') but JDBC's getTables metadata does not
   expose the partition strategy or key columns. The new enrichment runs a
   targeted query against pg_partitioned_table joined to pg_class /
   pg_namespace, retrieving pg_get_partkeydef(c.oid) — which returns the
   verbatim right-hand side of a PARTITION BY clause: "RANGE (col)",
   "LIST (region)", "HASH (id)", "RANGE (lower(email))" for functional
   keys, etc. — and stamps it onto matching rows in the existing returnList
   as a synthetic PARTITION_BY column, keyed on (TABLE_SCHEM, TABLE_NAME).

   This mirrors the index-USING enrichment pattern added in PR liquibase#6901 (which
   lives in the same file under getIndexInfo). The schema and tableName
   scoping clauses mirror that pattern as well; the table is small (one row
   per partitioned parent) so the cost is negligible.

   queryPostgres' throws-clause gains DatabaseException (already declared
   on both callers, fastFetchQuery / bulkFetchQuery).

2. liquibase.snapshot.jvm.TableSnapshotGenerator.readTable
   New branch: when database instanceof PostgresDatabase, read the
   PARTITION_BY enrichment column off the CachedRow and call
   table.setPartitionBy(...). Existing readTable behaviour for all other
   dialects (and for non-partitioned PG tables, which have null
   PARTITION_BY after enrichment) is unchanged.

3. liquibase.diff.output.changelog.core.MissingTableChangeGenerator.fixMissing
   When the reference database is PostgresDatabase and the missing Table
   has a partitionBy attribute set, propagate it onto the produced
   CreateTableChange. This is the final hop that gets the value into the
   serialized <createTable> XML.

Tests
-----
New: TableSnapshotGeneratorTest (3 cases, Spock)

  readTable picks up PARTITION_BY enrichment column when database is
    PostgresDatabase — CachedRow with PARTITION_BY="RANGE (test_date_int)"
    yields table.getPartitionBy() == "RANGE (test_date_int)"

  readTable does not set partitionBy when PARTITION_BY column is absent
    — CachedRow without PARTITION_BY yields null partitionBy.

  readTable ignores PARTITION_BY column on non-Postgres databases (safety
  guard) — even with PARTITION_BY="..." on the row, MySQLDatabase yields
  null partitionBy. Guards against accidental cross-dialect leakage.

New cases in MissingTableChangeGeneratorTest (Spock, 2 added):

  fixMissing propagates partitionBy from Postgres reference Table onto
  CreateTableChange — Table.partitionBy="RANGE (test_date_int)" with
  referenceDatabase=PostgresDatabase yields a CreateTableChange whose
  getPartitionBy() returns the same string.

  fixMissing leaves partitionBy null when reference Table has no
  partition spec — sanity guard that the propagation doesn't accidentally
  inject empty strings.

Manual end-to-end verification against postgres:16 in colima:
  CREATE TABLE public.test_tbl_part (test_date_int integer NOT NULL,
      PRIMARY KEY (test_date_int)) PARTITION BY RANGE (test_date_int);
  CREATE TABLE public.test_tbl_part_2026 PARTITION OF public.test_tbl_part
      FOR VALUES FROM (20260101) TO (20270101);

  $ liquibase generate-changelog ...

  Before (current main, baseline):
    <createTable tableName="test_tbl_part">
        <column name="test_date_int" type="INTEGER">...</column>
    </createTable>

  After (this commit):
    <createTable partitionBy="RANGE (test_date_int)" tableName="test_tbl_part">
        <column name="test_date_int" type="INTEGER">...</column>
    </createTable>

  Diff confined to the new partitionBy attribute (plus changeSet id
  timestamps, which are wall-clock-dependent and not meaningful).

Regression check: 249 tests pass across the *Table*, *Snapshot*, *Missing*,
*Changed* matchers (CreateTableGeneratorTest, CreateTableChangeTest,
TableSnapshotGeneratorTest, MissingTableChangeGeneratorTest,
TableComparatorTest, CreateTableGeneratorInformixTest,
CreateTableGeneratorPostgresTest, CreateTableStatementTest, plus the
snapshot-id and parser tests caught by the glob). 0 failures.

Fixes liquibase#6885
Closes liquibase#1874
Refs liquibase#7215

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…or partitionBy attribute (refs liquibase#6885)

Completes the user-facing surface of the liquibase#6885 fix:

1. XSD: `<xsd:attribute name="partitionBy" type="xsd:string"/>` on the
   `createTable` element in dbchangelog-latest.xsd. Without this, IDE XML
   validators (the Liquibase XSD ships with) flag `partitionBy` as an
   unknown attribute, which would be a poor user experience even though
   the runtime parser accepts unknown attributes via the existing
   `<xsd:anyAttribute namespace="##other" .../>` slot.

2. ChangeDefinitionTest.yaml: golden-file entry for the createTable
   `partitionBy` property under postgresql-only support. This file is
   regenerated against the @DatabaseChangeProperty annotation metadata
   by ChangeDefinitionTest at test time — without this entry, that test
   would fail because the auto-generated definition for createTable
   includes the new property and the YAML didn't.

3. PostgreSQLIntegrationTest.testSnapshotPartitionedTableCapturesPartitionBy
   End-to-end regression test. Mirrors PR liquibase#6901's pattern
   (testSnapshotIndexSnapshotsIndexFunction in the same file):
     a. Creates `CREATE TABLE part_test (id BIGINT, sold_at DATE NOT NULL)
        PARTITION BY RANGE (sold_at)` via raw SQL on the test database.
     b. Calls DiffGeneratorFactory.compare and produces a changelog via
        DiffToChangeLog.generateChangeSets.
     c. Asserts the resulting CreateTableChange.getPartitionBy() is set
        and contains both "RANGE" and "sold_at" (case-insensitive — the
        exact case returned by pg_get_partkeydef varies by PG version).
     d. Always drops the test table in a finally block so the assertion
        path is hermetic.

   Pre-fix, this test would have asserted false on step (c). Post-fix
   it asserts true. The test only runs against postgresql test systems
   (gated by assumeNotNull(this.getDatabase())).

Manual end-to-end verification against postgres:16 in colima already
showed the diff confined to the partitionBy attribute (see commit message
of `fix(postgres): capture PARTITION BY in snapshot...`).

Out of scope (deliberate)
-------------------------
- Child partitions: `CREATE TABLE child PARTITION OF parent FOR VALUES ...`
  still emit as standalone <createTable> entries without partition-of
  linkage. Users continue to add `<sql>create table child partition of
  parent ...</sql>` change sets manually. A follow-up PR can add
  pg_inherits-based enumeration + a partitionOf attribute. Not in this
  PR because it doubles the surface area and the maintainer's guidance
  in liquibase#6885 referenced only the parent property.

- ChangedTableChangeGenerator: no propagation added. That generator only
  produces SetTableRemarksChange today (and warns about tablespace
  changes). Postgres itself cannot ALTER a table's partition spec —
  changing it requires DROP+CREATE+data migration, which is outside
  Liquibase's diff-changelog scope. No new behaviour here.

Refs liquibase#6885

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…refs liquibase#6885)

PR liquibase#6901 added the index `using` attribute to BOTH dbchangelog-latest.xsd
AND the versioned dbchangelog-5.0.xsd (which is the schema URL emitted by
default in changelog headers on Liquibase 5.x). The earlier commit
"test(postgres): add liquibase#6885 integration test + XSD/YAML docs for partitionBy"
on this branch only updated -latest.xsd, mirroring an incomplete reading
of the liquibase#6901 pattern.

Consequence pre-fix: PostgreSQLIntegrationTest.testRerunDiffChangeLog (and
any other test that reparses a generated changelog with the canonical 5.0
namespace URL) fails XSD validation:

  ChangeLogParseException: ... cvc-complex-type.3.2.2: Attribute
  'partitionBy' is not allowed to appear in element 'createTable'.

Fix: add the same `<xsd:attribute name="partitionBy" type="xsd:string"/>`
to dbchangelog-5.0.xsd in the same position (after rowDependencies, before
the trailing <xsd:anyAttribute>), exactly mirroring the placement chosen
in -latest.xsd and in PR liquibase#6901's createIndex update to the same file.

No older versioned XSDs (1.0 through 4.33) are touched; those remain
frozen with their historical content, same as the index-USING precedent.

Refs liquibase#6885

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

… password-clearing in CommandScope

testStatusRunDuringUpdate reused a single CommandScope across three
sequential .execute() calls (statusCheckBefore, statusCheckDuring,
statusCheckAfter). PR liquibase#7741 ("CWE-316: clear password memory after use in
legacy CLI + CommandScope", 4850342, 2026-05-21) added a finally block
to CommandScope.execute() that overwrites credential-shaped argument
values (password, passwd, secret, token, apikey, accesskey) with "*****"
after the pipeline runs. This is the right hardening for the production
single-execute use of CommandScope, but it makes a single CommandScope
instance single-use:

  CommandScope scope = ...; // password=LiquibasePass1
  scope.execute();           // password gets overwritten to "*****"
  scope.execute();           // 2nd run authenticates with "*****" -> FATAL

Symptom on current upstream/main when running this test:

  liquibase.exception.DatabaseException: ...
  Connection could not be created to jdbc:postgresql://localhost:NNNN/lbcat:
  FATAL: password authentication failed for user "lbuser"
    at PostgreSQLIntegrationTest.testStatusRunDuringUpdate(line 93)

Line 93 is the second commandScope.execute() — statusCheckDuring. The
first .execute() (statusCheckBefore) succeeds; the second fails because
the scope's credential argument has been wiped.

Fix: build a fresh CommandScope per snapshot via the existing
`getStatusCommandScope(changelogFile)` helper, which constructs a new
scope and re-applies username/password from `testSystem`. Each .execute()
runs against an unwiped credential storage. Test logic, assertions, and
timing semantics are otherwise unchanged.

Verified locally against postgres:15 in colima — the test now passes
deterministically. Reproduced the failure on pure upstream/main (no
other changes) before the fix to confirm this is a regression of the
upstream commit, not something this branch introduced.

This commit is independent of liquibase#6885 — surfacing it here only because it
was the last red item blocking the local pre-push test run. If the
maintainers prefer, this single commit can be cherry-picked into a
standalone PR; it is fully self-contained and small.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…javadoc, message, deprecation, ChangedTable warning, edge-case tests

Five small fixes surfaced by self-review against the patterns CodeRabbit, Copilot,
and GitHub Advanced Security flag on Liquibase PRs (liquibase#7464, liquibase#6901, liquibase#7741). All
defensible individually; rolled up to keep the polish off the load-bearing commits.

1. JdbcDatabaseSnapshot.enrichPostgresqlTablesResult — fix empty `{@link }`
   javadoc tag.
   Inside the method's javadoc the original referent of pg_get_partkeydef was
   written as `{@link }` (no target) because pg_get_partkeydef is a SQL function,
   not a Java identifier the javadoc tool can resolve. Replaced with
   `{@code pg_get_partkeydef(oid)}` — semantically a code reference, no broken
   link warning from javadoc:jar.

2. CreateTableGenerator.warn — clarify warning text.
   Pre: "partitionBy clause is only supported on PostgreSQL; X will silently ignore it"
   Post: "partitionBy is only supported on PostgreSQL; the clause will be dropped
        from the generated SQL for X"
   "silently ignore" implied the clause was emitted and the target db ignored it.
   In reality the CreateTableGenerator skips the append entirely for non-PG, so
   the clause is dropped at generation, not silently ignored at apply time.
   The existing test (testWarnEmittedForPartitionByOnNonPostgresDatabase) still
   passes — it asserts case-insensitive "partition" in the message.

3. TableSnapshotGenerator.readTable — use non-deprecated trimToNull for the new
   partitionBy read.
   The previous commit `fix(postgres): capture PARTITION BY in snapshot ...`
   added `liquibase.util.StringUtil.trimToNull(...)` which is marked
   `@Deprecated` (javadoc points at `org.apache.commons.lang3.StringUtils.trimToNull`).
   GitHub Advanced Security's code-scanning bot flags any new use of the
   deprecated overload in PR diffs (verified on PR liquibase#7464 line — issue 2245).
   Switched the one new call site to `org.apache.commons.lang3.StringUtils`.
   The five surrounding pre-existing `StringUtil.trimToNull` calls in readTable
   are left untouched — they're not new code and a wholesale migration of
   readTable is out of scope for liquibase#6885.

4. ChangedTableChangeGenerator.fixChanged — warn on partitionBy diff.
   Mirrors the existing tablespace-change warning a few lines above. Without
   this, a user who changes a table's `partitionBy` between two snapshots gets
   a silent no-op changelog (the diff sees the difference but neither emits a
   change nor warns). Postgres declarative partitioning can't be ALTER'd —
   the parent table has to be dropped and recreated. Tell the operator
   explicitly rather than producing a deceptively-empty diff.
   No unit test added: ChangedTableChangeGeneratorTest does not exist in the
   repo, and the existing tablespace-change warning is similarly untested at
   the unit level. Following precedent.

5. CreateTableGeneratorPostgresTest — add 4 verbatim-passthrough cases.
   pg_get_partkeydef returns several shapes that the existing single test
   (RANGE on a single column) didn't exercise:
   - testGenerateSqlEmitsVerbatimForMultiColumnRangeKey: "RANGE (a, b)"
   - testGenerateSqlEmitsVerbatimForFunctionalKey:       "RANGE (lower(email))"
   - testGenerateSqlEmitsVerbatimForQuotedIdentifier:    'RANGE ("MixedCaseCol")'
   - testGenerateSqlEmitsListAndHashStrategiesVerbatim:  "LIST (region)", "HASH (user_id)"
   All four assert the generator passes the partitionBy string through
   unchanged — confirming the design decision (D4 in the brief: verbatim,
   no normalization) is enforced by tests.

Regression check: 6080 tests pass across liquibase-standard, 0 failures,
12 environment-dependent skips (normal). 7 cases now in
CreateTableGeneratorPostgresTest (3 prior + 4 added).

Refs liquibase#6885

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…h guard, blank-input normalization, PG10 test gate (refs liquibase#6885, PR liquibase#7759)

CodeRabbit posted 3 actionable findings + 1 nitpick on PR liquibase#7759
(liquibase#7759); all four addressed here.

1. JdbcDatabaseSnapshot.enrichPostgresqlTablesResult — exclude CockroachDB.
   `CockroachDatabase extends PostgresDatabase`, so our existing guard
   `if (!(database instanceof PostgresDatabase) ...)` allowed Cockroach
   targets to fall into the enrichment path and run
   `pg_get_partkeydef` / `pg_partitioned_table` queries against catalogs
   that Cockroach does not expose with the same semantics — the snapshot
   would fail. Added an explicit `database instanceof CockroachDatabase`
   check to the early-return guard.
   Note: PR liquibase#6901's index-USING enrichment a few methods up in the same
   file has the identical guard gap (CodeRabbit's claim that the index
   path already excludes Cockroach is incorrect — we re-verified). Same
   fix shape should land there in a separate follow-up; out of scope for
   liquibase#6885.

2. CreateTableChange.generateCreateTableStatement — trim-to-null partitionBy.
   The raw `getPartitionBy()` was forwarded into the statement without
   normalization, so a whitespace-only attribute value
   (`<createTable partitionBy=" ">`) would have made the SQL generator
   emit a stray, malformed `... PARTITION BY ` clause. Now wrapped in
   `StringUtils.trimToNull(...)`, mirroring how the same method
   normalizes `tablespace` via `StringUtil.trimToNull(getTablespace())`
   in `generateStatements`.

3. CreateTableGenerator.generateSql — defense-in-depth trim-to-null.
   Even with fix (2) above, a programmatically-constructed
   `CreateTableStatement` (from a future change type, or from external
   code that builds statements directly) could still arrive with a
   whitespace-only `partitionBy`. The generator now also runs
   `StringUtils.trimToNull` on the value before deciding whether to
   append the clause.

4. PostgreSQLIntegrationTest.testSnapshotPartitionedTableCapturesPartitionBy
   — gate on PostgreSQL 10+.
   Declarative partitioning syntax (`PARTITION BY`) was introduced in
   PostgreSQL 10. Other tests in this file gate on
   `assumeTrue(getDatabase().getDatabaseMajorVersion() >= N)` for
   feature-version-dependent setup (e.g. `>= 12` for generated columns);
   matching that pattern here so the test is gracefully skipped on
   pre-PG10 setups instead of failing with a SQL syntax error.

Tests
-----
- CreateTableGeneratorPostgresTest grew from 7 to 8 cases; new
  `testGenerateSqlNormalizesBlankPartitionByToNull` exercises six
  blank-shaped inputs ("", " ", "   ", "\t", "\n", " \n\t ") and asserts
  none of them produce a `PARTITION BY` substring in the output.
- All 126 tests across CreateTableGeneratorPostgresTest (8),
  CreateTableChangeTest (62), TableSnapshotGeneratorTest (3),
  MissingTableChangeGeneratorTest (5), and ChangeDefinitionTest (48) pass.

Refs liquibase#6885
Refs PR liquibase#7759

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…quibase#6885, PR liquibase#7759 review)

Addresses the sole blocker in @filipelautert's CHANGES_REQUESTED review
on PR liquibase#7759:

> `PARTITION BY` is emitted *after* `TABLESPACE`, but Postgres grammar
> requires the opposite order:
>   `(columns) [PARTITION BY ...] [USING ...] [WITH ...] [ON COMMIT ...] [TABLESPACE ...]`
> Any user with both `partitionBy` AND `tablespace` set will get a
> syntax error from Postgres.

Fix
---
`CreateTableGenerator.generateSql` previously emitted the TABLESPACE
block (lines 358-366) before the PARTITION BY block (lines 369-374).
The two blocks are now swapped: PARTITION BY appends first, TABLESPACE
appends after. Matches the canonical PG `CREATE TABLE` clause order
documented at https://www.postgresql.org/docs/current/sql-createtable.html.

The swap is purely textual: each block is self-contained, neither depends
on the other's state, and the surrounding blocks (MySQL autoincrement
options at line 353-356, MySQL COMMENT at line 376-378, Oracle
ROWDEPENDENCIES at line 380-382) are unaffected.

Test
----
`CreateTableGeneratorPostgresTest.testGenerateSqlEmitsPartitionByBeforeTablespace`
— new test, asserts the exact emitted SQL is
`CREATE TABLE public.part_with_ts (id INTEGER, created_at INTEGER) PARTITION BY RANGE (created_at) TABLESPACE my_ts`
with both a string-equality check and a defensive index-order check
(PARTITION BY index < TABLESPACE index) in case whitespace drifts later.

`CreateTableGeneratorPostgresTest` grew from 8 to 9 cases; full
`CreateTableGeneratorTest` (55 cases, all dialects) still passes —
the swap is invisible to any statement that doesn't set partitionBy,
which is everything outside Postgres.

Regression check: 182 tests pass across CreateTableGeneratorPostgresTest,
CreateTableGeneratorTest, CreateTableChangeTest, TableSnapshotGeneratorTest,
MissingTableChangeGeneratorTest, ChangeDefinitionTest.

Refs liquibase#6885
Refs PR liquibase#7759

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>