| From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
|---|---|
| To: | Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support EXCEPT for ALL SEQUENCES publications |
| Date: | 2026-04-13 04:27:32 |
| Message-ID: | CAHut+PsGFPE7vEpp1UrW1bjRHvNChL6aQErAt6Ugc-VtV93G3w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-04-13 04:35:03 | Add bms_offset_members() function for bitshifting Bitmapsets |
| Previous Message | vignesh C | 2026-04-13 04:22:00 | Re: Support EXCEPT for ALL SEQUENCES publications |