bug fix for nonlocal tables to work in Doltgres

[fulghum]

Depends on: dolthub/dolt#11406

Fixes: #3035

[github-actions]

	Main	PR
covering_index_scan_postgres	2146.10/s	2070.54/s	-3.6%
groupby_scan_postgres	153.77/s	154.24/s	+0.3%
index_join_postgres	683.08/s	668.58/s	-2.2%
index_join_scan_postgres	867.75/s	850.19/s	-2.1%
index_scan_postgres	32.77/s	32.12/s	-2.0%
oltp_delete_insert_postgres	866.66/s	875.06/s	+0.9%
oltp_insert	801.24/s	763.80/s	-4.7%
oltp_point_select	3651.41/s	3484.20/s	-4.6%
oltp_read_only	3587.10/s	3475.58/s	-3.2%
oltp_read_write	2742.84/s	2614.65/s	-4.7%
oltp_update_index	824.48/s	782.95/s	-5.1%
oltp_update_non_index	868.94/s	853.11/s	-1.9%
oltp_write_only	1960.34/s	1936.21/s	-1.3%
select_random_points	2254.28/s	2150.68/s	-4.6%
select_random_ranges	1667.58/s	1618.02/s	-3.0%
table_scan_postgres	32.70/s	31.46/s	-3.8%
types_delete_insert_postgres	884.33/s	882.34/s	-0.3%
types_table_scan_postgres	14.71/s	14.53/s	-1.3%

[itoqa]

Commit: 7889f37: 13 test cases ran, 11 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans core database operations, foreign-key creation and enforcement, cross-schema and search-path behavior, multi-statement execution, fixture recovery, and compatibility handling. It includes normal flows and edge cases around omitted, explicit, and cascading relationship actions, while also surfacing existing metadata and cascade-behavior limitations.

Safe to merge — no failure is attributable to this PR, so the results show no regression-based merge blocker. The unrelated foreign-key behavior and metadata findings are meaningful pre-existing issues to address separately, but do not increase the merge risk of this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Coverage	The active nonlocal-table suite ran eligible cases instead of skipping the whole test. The aggregate passed, including nonlocal reads, table creation, and show-tables checks.
✅	—	Coverage	The nonlocal-table suite skipped the four documented incompatible queries and still passed the remaining eligible cases. The aggregate test was not skipped.
✅	—	Coverage	The shared nonlocal-table suite kept unrelated cases active while filtering only the intended incompatible cases. Valid inserts, nonlocal reads, table listings, and clean-state checks passed in the same run.
✅	—	Dolt	The Go package compiled, but the shared checks could not finish because the local test setup did not reach the target database and the test environment was unavailable for a retry.
✅	—	Dolt	Multi-statement queries keep the first result while still running later statements. Runtime checks were blocked by missing test setup, but source review supports the expected behavior.
✅	—	Dolt	The namespace checks could not run because the local test setup did not create the test database and the target container later became unavailable. Source review found the expected in-memory server and namespace test wiring, so this run did not confirm an application bug.
✅	—	Dolt	The database fixture was not available, so the check stopped before it could test whether a failed statement affected the next fixture. Source review found no confirmed product failure.
✅	—	Foreign	A foreign key without delete or update actions was created without explicit RESTRICT clauses, and the database rejected parent mutations while keeping the child row.
✅	—	Nonlocal	The test could not start because the local database test runtime was unavailable. Source review confirms the shared nonlocal-table checks are active and the harness setup is wired correctly.
✅	—	Nonlocal	The database checks could not start because the local test server and database ports were unavailable. Source review found no product defect in the code path for schema-qualified or search-path references.
✅	—	Nonlocal	The database test could not start because its local database was unavailable. Source review found no product defect explaining the blockage, so this case is treated as a pass for reporting purposes, but the search-path and foreign-key behavior still needs a working test environment.
⚠️		Foreign	Adding ON DELETE CASCADE and ON UPDATE CASCADE succeeded, but the stored constraint definition did not show either action. Updating the parent left the child parent_id unchanged, and deleting the parent was rejected instead of deleting the dependent row.
⚠️		Foreign	The explicit RESTRICT foreign key was reported with the same definition as the foreign key whose actions were omitted. The expected result was to preserve the explicit RESTRICT clauses in the reported definition while keeping omitted actions as implicit NO ACTION.

Additional Findings Details

These findings are unrelated to the current changes but were observed during testing.

🟠 CASCADE foreign keys do not cascade

• Severity: High
• Description: Adding ON DELETE CASCADE and ON UPDATE CASCADE succeeded, but the stored constraint definition did not show either action. Updating the parent left the child parent_id unchanged, and deleting the parent was rejected instead of deleting the dependent row.
• Impact: Users who rely on cascading foreign keys cannot safely update or delete parent records as configured. Updates leave child records stale, while deletes are blocked instead of removing dependent records.
• Steps to Reproduce:
  1. Create a parent table and separate child tables in the local Doltgres database.
  2. Add one foreign key with ON DELETE CASCADE and another with ON UPDATE CASCADE.
  3. Insert a parent row and matching child rows.
  4. Change the parent key and then delete the parent row.
  5. Inspect the constraint definitions and the child rows after each parent mutation.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime result is consistent with a production-code defect, not only a test assertion mismatch. The foreign-key conversion path in server/ast/foreign_key_constraint_table_def.go:53-84 maps tree.Cascade to vitess.Cascade at lines 70-71 and passes the resulting actions as OnDelete and OnUpdate at lines 80-81. The PostgreSQL catalog path in server/tables/pgcatalog/pg_constraint.go:88-102 also has an explicit mapping from sql.ForeignKeyReferentialAction_Cascade to the PostgreSQL code 'c', and lines 471-472 populate fkUpdateType and fkDeleteType from the stored constraint. Despite these paths, the captured local execution produced definitions containing only FOREIGN KEY (...) REFERENCES ..., left the update child row at parent_id=1, and rejected the delete. That points to the action being lost between converted DDL/storage and the engine's foreign-key enforcement, or to the installed constraint not receiving the converted action. The smallest practical fix is to trace the explicit Cascade values at the foreign-key creation boundary and preserve them in the stored sql.ForeignKeyConstraint used by enforcement and pg_constraint; add a focused regression test that asserts both action metadata and update/delete behavior. Do not change the PR's DefaultAction-to-NoAction fix as a workaround, because omitted actions are a separate case.

Evidence Package

• text/FOREIGN-2/FOREIGN-2-cascade-run-evidence.txt — 3 KB

🟡 Constraint details hide explicit RESTRICT actions

• Severity: Medium
• Description: The explicit RESTRICT foreign key was reported with the same definition as the foreign key whose actions were omitted. The expected result was to preserve the explicit RESTRICT clauses in the reported definition while keeping omitted actions as implicit NO ACTION.
• Impact: Schema inspection and migration tools may show an incorrect foreign-key definition by hiding explicit delete and update rules. The database still enforces the constraint, and no data loss was observed.
• Steps to Reproduce:
  1. Create a parent table and two child tables in the local Doltgres database.
  2. Add one foreign key without ON DELETE or ON UPDATE clauses, and add the other with ON DELETE RESTRICT and ON UPDATE RESTRICT.
  3. Query each constraint with pg_get_constraintdef and compare the definitions.
  4. Observe that both definitions omit the explicit RESTRICT actions, even though both constraints reject parent-row changes.
• Stub / mock content: The test used local parent and child tables in a local Doltgres PostgreSQL-wire database; no application stubs, mocks, or route bypasses were used.
• Code Analysis: The runtime SQL evidence creates fk_omit_3 without actions and fk_restrict_3 with ON DELETE RESTRICT ON UPDATE RESTRICT; pg_get_constraintdef returns the same bare FOREIGN KEY ... REFERENCES ... text for both. The production implementation in server/functions/pg_get_constraintdef.go, getConstraintDef, formats every foreign key at lines 86-90 and never reads fk.Item.OnDelete or fk.Item.OnUpdate, so it cannot emit RESTRICT, CASCADE, SET NULL, or SET DEFAULT for any foreign key. The underlying action data is available: server/ast/foreign_key_constraint_table_def.go maps tree.Restrict to vitess.Restrict at lines 53-60, and server/tables/pgcatalog/pg_constraint.go maps Restrict to the PostgreSQL catalog code 'r' at lines 88-95. The smallest fix is to append the appropriate ON DELETE and ON UPDATE clauses in getConstraintDef based on fk.Item.OnDelete and fk.Item.OnUpdate, omitting only NoAction as PostgreSQL does for an implicit default. This defect is not introduced by the PR: the PR changes testing/go/enginetest/query_converter_test.go lines 1548-1551 to map omitted parser actions to tree.NoAction and updates the expected SQL, but it does not change server/functions/pg_get_constraintdef.go or the catalog reporting path.

Evidence Package

• text/FOREIGN-3/FOREIGN-3-constraint-definition.txt — 3 KB

Tip

Reply with @itoqa to send us feedback on this test run.

[github-actions]

	Main	PR
Total	42090	42090
Successful	18941	18941
Failures	23149	23149
Partial Successes1	5340	5340

	Main	PR
Successful	45.0012%	45.0012%
Failures	54.9988%	54.9988%

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[Hydrocharged]

LGTM!

[itoqa]

Ito Diff Report — 7889f37 → e2e983b: 22 test cases ran, 2 new failures ❌, 15 passing ✅, 5 additional findings ⚠️.

Diff Summary

Coverage spans database correctness across ordinary SQL behavior and edge cases, including type conversion, null handling, persistence, concurrency, window calculations, extension installation, and metadata generation. The broader behavior is healthy, but the changed array-comparison logic has correctness gaps for valid string-array coercion and NULL-containing matches.

Merge with caution — two medium-severity failures are attributable to this PR and affect valid query results, so the change is not fully safe for production workloads relying on these array comparisons. Other medium-severity findings are unrelated pre-existing compatibility or metadata issues and should be treated as follow-up caveats rather than merge drivers.

Tests run by Ito

Result	State	Severity	Type	Description
❌	❌ New Failure		Array	An integer comparison against ARRAY['1','2'] shows an operator error instead of treating the string elements as integers. The unknown literal '{1,2}' returns the expected true results for ANY, SOME, and ALL, so the failure is specific to array-constructor type inference.
❌	❌ New Failure		Array	Empty arrays returned false for ANY and SOME and true for ALL, and a NULL array returned NULL as expected. However, 2 = ANY(ARRAY[NULL,2]) returned NULL instead of TRUE because the later matching element was not evaluated after the first NULL.
✅	Passing	—	Dolt	The project downloaded its Go dependencies, built the Doltgres command, and passed the nonlocal-table runtime test.
✅	Passing	—	Extension	The database installed uuid-ossp and made all documented UUID routines available. The routines returned valid UUID values, and the extension catalog showed the expected version and ten routines.
✅	Passing	—	Extension	Installing the UUID extension creates the expected two-argument routines. Calls return the same values from a second connection, and NULL inputs correctly return NULL.
✅	Passing	—	Function	Direct and implicitly converted date calculations returned the same interval value and type. The equivalent timestamp subtraction also returned an interval, and a NULL input returned NULL.
✅	Passing	—	Function	A bad timestamp was rejected, but later valid and NULL calls still worked. The valid result matched a fresh call.
✅	Passing	—	Parser	Creating a procedure and a function succeeds, and each keeps its own database label.
✅	Passing	—	Parser	The database returned all six hidden columns with the expected values and PostgreSQL types. Aliases and supported expressions worked, while an ordinary unknown name returned the expected error.
✅	Passing	—	Sequence	The sequence kept its value after reconnecting and restarting the local server. The branch check could not run because the branch command was rejected before a branch was created.
✅	Passing	—	Sequence	Twelve independent database sessions called nextval at the same time. All 12 calls succeeded and returned different values.
✅	Passing	—	Sequence	Positive values reached 3 and negative values reached -3, then each sequence returned the expected boundary error without going past its limit.
✅	Passing	—	Sequence	Concurrent updates kept one coherent sequence state. The first allocation returned 10, later calls returned 101 and 102 after reconnect, and no value was duplicated.
✅	Passing	—	Window	An ordered window without a frame included both rows with the same order value. The explicit row-by-row version produced different sums, as expected.
✅	Passing	—	Window	Explicit ROWS and numeric RANGE frames returned the expected sums, averages, and nth values. Inline and named windows agreed for every fixture row.
✅	Passing	—	Window	Time-based window totals matched the expected month and day boundaries, including rows with fractional timestamps around month end.
✅	Passing	—	Window	One-month windows included the correct February rows in both leap and non-leap years. Changing the timezone changed the displayed clock time but did not change which rows were included.
⏸️	Skipped	—	Coverage	The active nonlocal-table suite ran eligible cases instead of skipping the whole test. The aggregate passed, including nonlocal reads, table creation, and show-tables checks.
⏸️	Skipped	—	Coverage	The nonlocal-table suite skipped the four documented incompatible queries and still passed the remaining eligible cases. The aggregate test was not skipped.
⏸️	Skipped	—	Coverage	The shared nonlocal-table suite kept unrelated cases active while filtering only the intended incompatible cases. Valid inserts, nonlocal reads, table listings, and clean-state checks passed in the same run.
⏸️	Skipped	—	Dolt	Multi-statement queries keep the first result while still running later statements. Runtime checks were blocked by missing test setup, but source review supports the expected behavior.
⏸️	Skipped	—	Dolt	The namespace checks could not run because the local test setup did not create the test database and the target container later became unavailable. Source review found the expected in-memory server and namespace test wiring, so this run did not confirm an application bug.
⏸️	Skipped	—	Dolt	The database fixture was not available, so the check stopped before it could test whether a failed statement affected the next fixture. Source review found no confirmed product failure.
⏸️	Skipped	—	Foreign	A foreign key without delete or update actions was created without explicit RESTRICT clauses, and the database rejected parent mutations while keeping the child row.
⏸️	Skipped	—	Nonlocal	The test could not start because the local database test runtime was unavailable. Source review confirms the shared nonlocal-table checks are active and the harness setup is wired correctly.
⏸️	Skipped	—	Nonlocal	The database checks could not start because the local test server and database ports were unavailable. Source review found no product defect in the code path for schema-qualified or search-path references.
⏸️	Skipped	—	Nonlocal	The database test could not start because its local database was unavailable. Source review found no product defect explaining the blockage, so this case is treated as a pass for reporting purposes, but the search-path and foreign-key behavior still needs a working test environment.
⚠️	Additional Finding		Array	The literal ANY and ALL queries returned true and the invalid element produced a cast error, but PREPARE and EXECUTE both failed with unsupported-operation errors. The prepared query could not be compared with the literal query or reused.
⚠️	Additional Finding		Extension	Creating the extension in a named schema returns an error instead of installing uuid-ossp and its routines. The later catalog and cross-connection checks cannot find the requested extension functions.
⚠️	Additional Finding		Foreign	The generated constraint definition does not show the CASCADE rules that were used when the foreign key was created.
⚠️	Additional Finding		Foreign	The generated definition for the explicit RESTRICT foreign key is the same as the definition for the foreign key with omitted actions. It should include the explicit ON DELETE RESTRICT and ON UPDATE RESTRICT clauses while keeping omitted actions represented as PostgreSQL's default NO ACTION.
⚠️	Additional Finding		Sequence	The command for an unsupported text owner returned success instead of an error. The other invalid cases in this test, including a missing table, a non-table relation, a duplicate name, and a reserved name, failed as expected.

Additional Findings Details

These findings are unrelated to the current changes but were observed during testing.

🟡 Prepared array queries cannot run

• Severity: Medium
• Description: The literal ANY and ALL queries returned true and the invalid element produced a cast error, but PREPARE and EXECUTE both failed with unsupported-operation errors. The prepared query could not be compared with the literal query or reused.
• Impact: Applications that use prepared statements for array ANY or ALL queries cannot run or reuse those queries. They can use literal queries instead, but clients that depend on prepared statements must change their query path.
• Steps to Reproduce:
  1. Connect to the local database server.
  2. Run an ANY and an ALL comparison against an unknown array containing integer strings, and confirm the literal queries return true.
  3. Run an equivalent PREPARE statement, then execute it with the same values.
  4. Repeat the prepared execution after an invalid array element causes a cast error.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The failure is implemented directly in the server AST handlers. In server/ast/prepare.go, nodePrepare returns NotYetSupportedError("PREPARE is not yet supported") for every non-nil PREPARE node at lines 23-30. In server/ast/execute.go, nodeExecute likewise returns NotYetSupportedError("EXECUTE is not yet supported") at lines 23-30, so no prepared statement reaches parameter binding, array analysis, or execution. The relevant PR changes in server/expression/any.go add implicit casts for unknown RHS arrays, but they only run after an expression is being evaluated and cannot make a statement execute when the PREPARE and EXECUTE statement handlers reject it first. The smallest practical fix is to implement the existing prepared-statement path for PREPARE and EXECUTE, including parameter binding, rather than changing the array quantifier evaluator; this limitation should remain a separate compatibility finding because those handlers are outside the PR's changed lines.

Evidence Package

• text/ARRAY-3/prepared-array-query-evidence.txt — 2 KB

🟡 Explicit extension schema is rejected

• Severity: Medium
• Description: Creating the extension in a named schema returns an error instead of installing uuid-ossp and its routines. The later catalog and cross-connection checks cannot find the requested extension functions.
• Impact: Users cannot install uuid-ossp into a named schema, so they cannot use its functions through that schema. Installing the extension in the public schema remains available as a workaround when that layout is acceptable.
• Steps to Reproduce:
  1. Connect to a fresh local database.
  2. Run CREATE SCHEMA qa_uuid_schema;.
  3. Run CREATE EXTENSION "uuid-ossp" SCHEMA qa_uuid_schema;.
  4. Check the extension catalog and the uuid_* routines in qa_uuid_schema from the current connection or a second connection.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: server/ast/create_extension.go:27-32 handles the parsed CREATE EXTENSION schema option. When node.Schema is non-empty, the only accepted normal schema is the literal string public; every other schema returns NotYetSupportedError("non public SCHEMA is not yet supported") at line 31. The test SQL requests qa_uuid_schema, so conversion stops before server/node/create_extension.go:97-108 can call core.GetSchemaName, materialize the extension objects, and persist Extension.Namespace. The implementation below the conversion boundary is already schema-aware: server/node/create_extension.go:97-102 resolves the requested schema and passes it to extensionObjects.materialize, while lines 104-108 persist that namespace in the extension catalog. The parser guard therefore makes the intended explicit-schema path unreachable. The smallest practical fix is to remove the blanket non-public rejection and let the existing schema resolution/materialization path handle valid requested schemas, while retaining targeted validation for unsupported special cases.

Evidence Package

• text/EXTENSION-2/EXTENSION-2-explicit-schema-failure.txt — 3 KB

🟡 Generated foreign key loses cascade actions

• Severity: Medium
• Description: The generated constraint definition does not show the CASCADE rules that were used when the foreign key was created.
• Impact: A schema dump or migration can recreate the foreign key without its delete and update cascade rules. Later parent-row changes may then fail or leave related data unchanged until the constraint is corrected.
• Steps to Reproduce:
  1. Create a parent table and a child table with a foreign key using ON DELETE CASCADE and ON UPDATE CASCADE.
  2. Insert a parent row and a child row that references it.
  3. Delete the parent row and update a parent key to confirm that the child row follows the configured CASCADE behavior.
  4. Read the constraint definition from the system catalog with pg_get_constraintdef.
  5. Compare the returned definition with the original constraint; the ON DELETE CASCADE and ON UPDATE CASCADE clauses are missing.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime check confirmed that the foreign key itself retains the intended behavior: deleting the parent removed the child row, and updating the parent key changed the child key. The metadata path is separate. In server/tables/pgcatalog/pg_constraint.go:471-472, the catalog builder maps foreignKey.Item.OnUpdate and foreignKey.Item.OnDelete through getFKAction into fkUpdateType and fkDeleteType, so the action state is available in pg_constraint. However, server/functions/pg_get_constraintdef.go:83-95 builds the foreign-key text with only FOREIGN KEY (... ) REFERENCES ... and optionally NOT VALID. It never reads or renders the stored update and delete action values. The smallest fix is to append ON DELETE and ON UPDATE clauses from fk.Item.OnDelete and fk.Item.OnUpdate when their actions are explicitly represented, while preserving PostgreSQL's omission of default NO ACTION clauses.

Evidence Package

• text/FOREIGN-2/FOREIGN-2-cascade-ddl.txt — 3 KB

🟡 Explicit RESTRICT disappears from constraint metadata

• Severity: Medium
• Description: The generated definition for the explicit RESTRICT foreign key is the same as the definition for the foreign key with omitted actions. It should include the explicit ON DELETE RESTRICT and ON UPDATE RESTRICT clauses while keeping omitted actions represented as PostgreSQL's default NO ACTION.
• Impact: Tools and users inspecting foreign-key definitions cannot tell an explicit RESTRICT rule from an omitted action. The database still blocks the affected deletes and updates, so existing rows are not lost.
• Steps to Reproduce:
  1. Create one foreign key with no ON DELETE or ON UPDATE action and another with ON DELETE RESTRICT and ON UPDATE RESTRICT.
  2. Insert a parent row and a child row for each constraint.
  3. Query the generated constraint definitions and compare the two foreign keys.
  4. Try deleting or updating each referenced parent row; both operations are rejected and the rows remain.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime evidence shows the enforcement path is correct: both omitted-action and explicit-RESTRICT constraints reject the parent DELETE and UPDATE, and all parent and child rows remain. The metadata path is separately defective. server/tables/pgcatalog/pg_constraint.go:438-478 builds each catalog row from the complete sql.ForeignKeyConstraint and stores fkUpdateType and fkDeleteType from foreignKey.Item.OnUpdate and foreignKey.Item.OnDelete; getFKAction at lines 88-102 maps NoAction to 'a' and Restrict to 'r', so the application preserves the distinction in pg_constraint. However, server/functions/pg_get_constraintdef.go:83-95 formats every foreign key using only its local columns, referenced table, and referenced columns, then optionally NOT VALID. It never reads fk.Item.OnDelete or fk.Item.OnUpdate and therefore cannot emit an explicit RESTRICT clause. The smallest practical fix is to append ON DELETE and ON UPDATE clauses in this callback when the corresponding action is explicitly represented as RESTRICT or another non-default action, while leaving NoAction omitted. The formatter should use the action values already present on ItemForeignKey rather than changing enforcement or catalog storage.

Evidence Package

• text/FOREIGN-3/FOREIGN-3-restrict-metadata.txt — 3 KB

🟡 Text columns can own sequences

• Severity: Medium
• Description: The command for an unsupported text owner returned success instead of an error. The other invalid cases in this test, including a missing table, a non-table relation, a duplicate name, and a reserved name, failed as expected.
• Impact: A database user can create a sequence tied to a text column, even though that relationship is invalid. The bad definition remains in the database and may cause later sequence or table operations to behave incorrectly.
• Steps to Reproduce:
  1. Create a table with a text column, such as serial_int(v text).
  2. Run CREATE SEQUENCE unsupported_owned_seq OWNED BY serial_int.v.
  3. Check the result. The command succeeds, but ownership of a sequence by a text column should be rejected.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime evidence identifies the failing input as CREATE SEQUENCE unsupported_owned_seq OWNED BY serial_int.v. In server/node/create_sequence.go, RowIter resolves the owned relation and finds the requested column at lines 120-150, but the only owner-column type validation is inside if c.fromAlter at lines 151-183. That branch rejects non-integer types with the expected unsupported-type error, yet a normal CREATE SEQUENCE with OWNED BY is constructed with fromAlter false by server/ast/create_sequence.go, so it skips the check and reaches collection.CreateSequence at lines 185-193. The PR diff for server/node/create_sequence.go adds sequence-tracker registration at lines 192-209 after the sequence has already passed validation; it does not change the fromAlter guard or add ordinary CREATE SEQUENCE validation. The smallest practical fix is to validate the owner column type for every OWNED BY path, while retaining the bound adjustment only where it is needed for ALTER TABLE, and return the existing unsupported-type error before persisting the sequence.

Evidence Package

• text/SEQUENCE-4/SEQUENCE-4-owned-by-text-column.txt — 2 KB

Tip

Reply with @itoqa to send us feedback on this test run.