Re: Add support for specifying tables in pg_createsubscriber.

On 2025-08-01 Fr 11:03 AM, Zhijie Hou (Fujitsu) wrote:
> On Friday, August 1, 2025 8:56 PM Andrew Dunstan<andrew@dunslane.net> wrote:
>> On 2025-08-01 Fr 4:03 AM, Zhijie Hou (Fujitsu) wrote:
>>> On Monday, July 28, 2025 1:07 PM Hayato Kuroda (Fujitsu)
>>> mailto:kuroda.hayato@fujitsu.com wrote:
>>>> Dear Shubham,
>>>>
>>>> The attached patch introduces a new '--table' option that can be specified
>>>> after each '--database' argument.
>>>>
>>>> Do we have another example which we consider the ordering of options? I'm
>>>> unsure for it. Does getopt_long() always return parsed options with the
>>>> specified order?
>>>>
>>>> The syntax is like that used in 'vacuumdb' and supports multiple '--table'
>>>> arguments per database, including optional column lists and row filters.
>>>>
>>>> Vacuumdb nor pg_restore do not accept multiple --database, right? I'm afraid
>>>> that current API has too complex.
>>> 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.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com