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 →
-
Doc: Clarify that publication exclusions track table identity.
- 77b6dd909252 19 (unreleased) cited
-
Use schema-qualified names in EXCEPT clause error messages.
- a49b9cfd72d8 19 (unreleased) cited
-
psql: Improve describe footer titles for publications.
- 2e1d4fdb10e6 19 (unreleased) cited
-
Improve various new-to-v19 appendStringInfo calls
- 49ce41810fac 19 (unreleased) cited