Re: Add support for specifying tables in pg_createsubscriber.
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
'Shubham Khanna' <khannashubham1197@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-02T00:51:07Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Support existing publications in pg_createsubscriber.
- 85ddcc2f4cde 19 (unreleased) landed
On 2025-08-01 Fr 8:24 PM, Zhijie Hou (Fujitsu) wrote: > On Saturday, August 2, 2025 12:59 AM Andrew Dunstan <andrew@dunslane.net> wrote: >> On 2025-08-01 Fr 11:03 AM, Zhijie Hou (Fujitsu) wrote: >>> On Friday, August 1, 2025 8:56 PM Andrew Dunstan mailto:andrew@dunslane.net >> wrote: >> >>>>> We have another example to consider: pg_amcheck, which allows users to >>>>> specify multiple databases. >>>> I don't think that's quite the point, as I understand it. pg_amcheck might >>>> allow you to have multiple --database arguments, but I don't think it depends >>>> on the order of arguments. You didn't answer his question about what >>>> getopt_long() does. I don't recall if it is free to mangle the argument order. >>> I think you might misunderstand my proposal. I am suggesting an alternative >>> interface style that employs database-qualified table names, which doesn't >>> depend on the order of options. This style is already used by pg_amcheck when >>> dealing with multiple database specifications. I referenced pg_amcheck as an >>> example. >> I simple took your own description: The attached patch introduces a new >> '--table' option that can be specified after each '--database' argument. Maybe I >> need some remedial English, but to me that "after" says that argument order is >> significant. > Allow me to clarify the situation. The description you referenced is the > original interface proposed by the author in the initial email. However, it was > found to be unstable due to its reliance on the argument order. In response to > the discussion, instead of supporting the original interface, I suggested an > alternative interface to consider, which is the one that does not depend on > argument order, as I mentioned in my previous email. > Apologies, then, I misread the thread. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com