IIUC, the only purpose of the proposed '--table' spec is to allow some
users the ability to tweak the default "CREATE PUBLICATION p FOR ALL
TABLES;" that the 'pg_createsubscriber' tool would otherwise
construct.
But --table is introducing problems too: e.g.
- tricky option ordering rules (e.g. most recent --database if dbname
not specified?)
- too many --table may be needed; redundant repeating of databases and
schemas also seems very verbose.
- limitations for syntax (e.g. what about FOR TABLES IN SCHEMA?)
- limitations for future syntax (e.g. what about SEQUENCES?; what about EXCEPT?)
Can these problems disappear just by slightly changing the meaning of
the existing '--publication' option to allow specifying more than just
the publication name: e.g.
--publication = 'pub1' ==> "CREATE PUBLICATION pub1 FOR ALL TABLES;"
--publication = 'pub1 FOR TABLE t1,t2(c1,c2),t3' ==> "CREATE
PUBLICATION pub1 FOR TABLE t1,t2(c1,c2),t3;"
--publication = 'pub1 FOR TABLES IN SCHEMA s1' ==> "CREATE PUBLICATION
pub1 FOR TABLES IN SCHEMA s1;"
--publication = 'pub1 FOR ALL TABLES WITH
(publish_via_partition_root)' ==> "CREATE PUBLICATION pub1 FOR ALL
TABLES WITH (publish_via_partition_root);"
Here:
- no new ordering rules; --publication/--database rules are already
well-defined; nothing to do.
- no new options; minimal document changes
- no limitations on existing CREATE PUBLICATION syntax; minimal new code changes
- future proof for new CREATE PUBLICATION syntax; zero code changes
- expanding the '--publication' meaning could also be compatible with
Euler's idea [1] to reuse existing publications
~~~
This idea could be error-prone, but it's only for a small subset of
users who need more flexibility than the default pg_createsubscriber
provides. And while it might be typo-prone, so is --table (e.g.,
--table 'db.typo.doesnotexist' is currently allowed). Did you consider
this approach already? The thread seems to have started with --table
as the assumed solution without mentioning if other options were
discussed.
Thoughts?
======
[1] https://www.postgresql.org/message-id/30cc34eb-07a0-4b55-b4fe-6c526886b2c4%40app.fastmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia.
