Re: Support EXCEPT for ALL SEQUENCES publications - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Support EXCEPT for ALL SEQUENCES publications
Date
Msg-id CAHut+PsGFPE7vEpp1UrW1bjRHvNChL6aQErAt6Ugc-VtV93G3w@mail.gmail.com
Whole thread Raw
In response to Re: Support EXCEPT for ALL SEQUENCES publications  (Shlok Kyal <shlok.kyal.oss@gmail.com>)
Responses Re: Support EXCEPT for ALL SEQUENCES publications
List 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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Support EXCEPT for ALL SEQUENCES publications
Next
From: David Rowley
Date:
Subject: Add bms_offset_members() function for bitshifting Bitmapsets