Re: Support EXCEPT for ALL SEQUENCES publications

Peter Smith <smithpb2250@gmail.com>

From: Peter Smith <smithpb2250@gmail.com>
To: Shlok Kyal <shlok.kyal.oss@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-13T04:27:32Z
Lists: pgsql-hackers
Hi Shlok.

Before this patch goes too far, I had a fundamental question.

I understand that sequences and tables are closely related; sequences
are just like a single-row table, but they have a RELKIND_SEQUENCE.

There is a lot of shared code internally, so I guess it is tempting to
specify both the published sequences and tables together in the System
Catalog 'pg_publication_rels'.

I'm just wondering whether that is really the best way to go?

Currently, pg_publication_rels has only tables. So they might be:
* only included tables -- from a publication using "FOR TABLE ..."
* only excluded tables -- from a publication using "FOR ALL TABLES
EXCEPT (TABLE ...)"

Because included/excluded tables cannot co-exist, we can easily know
the type of the CREATE/ALTER PUBLICATION command and the type of
'pg_publication_rels' content without digging deeper.

~~~

But introducing sequences introduces complexity. Now, AFAICT, we
cannot know what each row of 'pg_publication_rels' means without
inspecting the relation type of that row. e.g. now we have lots of
possible combinations like.

pg_publication_rels has:
* only included tables.
* only excluded tables.
* only excluded sequences.
* excluded tables and excluded sequences.
* included tables and excluded sequences.

Furthermore, there will be yet more combinations one day if the
individual "FOR SEQUENCE ..." syntax is implemented.

pg_publication_rels has:
* only included sequences
* included sequences and included tables
* included sequences and excluded tables

IIUC, it means that the SQL everywhere now requires joins and relkind
checks to identify the type.

~~

Furthermore, AFAICT, the 'pg_publication_rels' attributes 'prattrs'
and 'prquals' don't even have meaning for sequences. That's another
reason why it feels a bit like a square peg was jammed into a round
hole just because 'pg_publication_rels' was conveniently available.

~~

SUMMARY

Given:
* Option 1 = use 'pg_publication_rels' for both tables and sequences.
* Option 2 = use 'pg_publication_rels' just for tables and use a new
'pg_publication_seq' just for sequences.

I'm not convinced that the chosen way (Option 1) is better. Can you
explain why it is?

======
Kind Regards,
Peter Smith.
Fujitsu Australia



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Doc: Clarify that publication exclusions track table identity.

  2. Use schema-qualified names in EXCEPT clause error messages.

  3. psql: Improve describe footer titles for publications.

  4. Improve various new-to-v19 appendStringInfo calls