Re: psql \watch 2nd argument: iteration count

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andrey Borodin <amborodin86(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sfrost(at)snowman(dot)net, peter(dot)eisentraut(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: psql \watch 2nd argument: iteration count
Date: 2023-03-13 01:17:12
Message-ID: ZA55mDWN+E7D7MBF@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-03-13 01:26:37 Re: psql \watch 2nd argument: iteration count
Previous Message Michael Paquier 2023-03-13 01:06:34 Re: Requiring recovery.signal or standby.signal when recovering with a backup_label