RE: Add support for specifying tables in pg_createsubscriber.

On Monday, August 25, 2025 8:08 AM Peter Smith  wrote:
> 
> 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);"

I think embedding commands directly in the option value poses SQL injection
risks, so is not very safe. We could directly allow users to use an existing
publication (as mentioned by Euler[1]).

[1] https://www.postgresql.org/message-id/30cc34eb-07a0-4b55-b4fe-6c526886b2c4%40app.fastmail.com

Best Regards,
Hou zj