Re: psql \watch 2nd argument: iteration count - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: psql \watch 2nd argument: iteration count
Date
Msg-id b69eb102-95f7-0ed6-2ce9-5fa93e0bedbf@enterprisedb.com
Whole thread Raw
In response to Re: psql \watch 2nd argument: iteration count  (Michael Paquier <michael@paquier.xyz>)
Responses Re: psql \watch 2nd argument: iteration count
List pgsql-hackers
On 13.03.23 02:17, Michael Paquier wrote:
> On Sun, Mar 12, 2023 at 01:05:39PM -0700, Andrey Borodin wrote:
>> In the review above Kyotaro-san suggested that message should contain
>> information on what it expects... So, maybe then
>> pg_log_error("\\watch interval must be non-negative number, but
>> argument is '%s'", opt); ?
>> Or perhaps with articles? pg_log_error("\\watch interval must be a
>> non-negative number, but the argument is '%s'", opt);
> 
> -       HELP0("  \\watch [SEC]           execute query every SEC seconds\n");
> +       HELP0("  \\watch [SEC [N]]       execute query every SEC seconds N times\n");
> 
> Is that really the interface we'd want to work with in the long-term?
> For one, this does not give the option to specify only an interval
> while relying on the default number of seconds.  This may be fine, but
> it does  not strike me as the best choice.  How about doing something
> more extensible, for example:
> \watch [ (option=value [, option=value] .. ) ] [SEC]
> 
> I am not sure that this will be the last option we'll ever add to
> \watch, so I'd rather have us choose a design more flexible than
> what's proposed here, in a way similar to \g or \gx.

On the other hand, we also have option syntax in \connect that is like 
-foo.  Would that be a better match here?  We should maybe decide before 
we diverge and propagate two different option syntaxes in backslash 
commands.




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Order changes in PG16 since ICU introduction
Next
From: Tom Lane
Date:
Subject: Re: psql \watch 2nd argument: iteration count