Re: Support EXCEPT for ALL SEQUENCES publications

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

In response to

Responses

Browse pgsql-hackers by date

  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