Skip to content

fix(plugins): address routines and triggers the way the engine spells them, and copy a table's sequences - #2568

Merged
datlechin merged 1 commit into
mainfrom
fix/copy-objects-sequences-and-drop-identity
Aug 29, 2026
Merged

fix(plugins): address routines and triggers the way the engine spells them, and copy a table's sequences#2568
datlechin merged 1 commit into
mainfrom
fix/copy-objects-sequences-and-drop-identity

Conversation

@datlechin

Copy link
Copy Markdown
Member

Follow-up to #2567. Two defects the copy feature exposed, both of which also affect released features.

A routine and a trigger are not addressed by name alone

SourceObjectSyncBuilder wrote every drop as DROP <keyword> schema.name. That is wrong on two counts, and both reach Compare & Sync, not just Copy To:

  • PostgreSQL allows f(integer) and f(text) in one schema, so DROP FUNCTION public.f is ambiguous and the server refuses it.
  • PostgreSQL spells a trigger drop DROP TRIGGER name ON table. Without the ON, every trigger drop failed.

MySQL is the opposite on both: it rejects the argument list and takes no ON. Only the driver knows which, so generateDropRoutineSQL(name:signature:schema:isFunction:) joins the existing generateDropTriggerSQL in PluginDatabaseDriver, with a nil default meaning "the caller's own qualified name is right for this engine". PostgreSQL implements it; every other driver inherits the old behaviour unchanged.

ObjectCopyPlanner also had to pass the trigger's owning table through, which it now does in the signature slot triggerReads already uses.

A copied table's default names a sequence that was never copied

PostgreSQL reports a SERIAL column as integer ... DEFAULT nextval('orders_id_seq'::regclass) and the driver keeps that text verbatim, so a copied table's CREATE either fails outright or, where the source's own sequence happens to be reachable, succeeds and leaves the copy handing out the original's keys.

fetchDependentSequences already existed and nothing called it. ObjectCopyPlanner now reads it for every table whose structure it writes and puts the result in a new ObjectCopyTableStep.sequenceStatements, which runs after the drop and before the create. A sequence several tables default from is created once, under the first of them in dependency order.

The driver's own DDL had a bug of its own here: the setval line spelled the schema it was read from while the CREATE SEQUENCE beside it was schema-relative. Run against another schema it repositioned the original sequence; against another database it named one that was not there. It is now unqualified, so the pair agrees. That fixes SQL export and the structure editor's DDL tab as well.

Verification

  • verify.sh build PASS, verify.sh test PASS (23 cases across the three suites), verify.sh lint 0 violations
  • verify.sh abi origin/main: two added lines, no removals, and the new requirement carries a default. Additive, so no currentPluginKitVersion bump and no plugin re-release.
  • verify.sh build PostgreSQLDriver PASS. verify.sh plugins fails locally on the oracle-nio fork's @TaskLocal macro, which is a known local-toolchain failure unrelated to this branch; CI compiles the aggregate.

New tests: SourceObjectSyncBuilderTests covers both dialect drops and the unchanged fallback for an engine that implements neither, and ObjectCopySequenceStatementTests covers the split, the termination and the ordering against the create.

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@datlechin
datlechin merged commit 9a5d3ba into main Aug 29, 2026
13 checks passed
@datlechin
datlechin deleted the fix/copy-objects-sequences-and-drop-identity branch August 29, 2026 03:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant