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
