Hi!
On Thu, Sep 3, 2026 at 6:38 AM Michael Paquier <michael@paquier.xyz> wrote:
> Sami has also mentioned to me off-list that we may want something
> smarter in terms of the management of the DefElems that include
> strings, because we have other commands with contents that we may want
> to normalize in some contexts, like an ALTER TABLE with a password as
> one example. Perhaps it would be better to not rush that part.
Agreed, so v3 attached drops the generic part and does WAIT only.
Two things today: waits differing only in the timeout get an entry
each, and so does the same wait with its options written in another
order.
1 | WAIT FOR LSN $1 WITH (mode 'primary_flush', timeout '5ms')
1 | WAIT FOR LSN $1 WITH (mode 'primary_flush', timeout '7ms')
1 | WAIT FOR LSN $1 WITH (timeout '5ms', mode 'primary_flush')
With v3 those are one entry:
3 | WAIT FOR LSN $1 WITH (mode 'primary_flush', timeout $2)
while the modes stay apart, as Sirisha asked for:
1 | WAIT FOR LSN $1 WITH (mode 'standby_replay', timeout $2, no_throw)
1 | WAIT FOR LSN $1 WITH (mode 'standby_write', timeout $2, no_throw)
WaitStmt.options gets a custom jumble function that walks the
recognized options in a fixed order instead of the order written,
records TIMEOUT as a constant, and jumbles MODE and NO_THROW as given.
No generic DefElem option normalization: what a value means differs
per option and only the command knows, which is the same problem
VariableSetStmt.jumble_args solves per grammar flavor.
DefElem gains arg_location, since DefElem.location points at the
option name -- recording that one normalizes the wrong token:
WAIT FOR LSN $1 WITH (mode 'primary_flush', $2 '5ms')
and the argument node is a bare String or Integer, which carries no
location at all. Nothing else reads the new field, so no other
statement changes.
One wart left alone: "WITH (no_throw)" and "WITH (no_throw true)" are
still separate entries, as VACUUM (ANALYZE) and VACUUM (ANALYZE true)
are today. Resolving it would mean calling defGetBoolean() while
jumbling, which can throw.
Passwords in pg_stat_statements are untouched by this and can go to
their own thread.
------
Regards,
Alexander Korotkov
Supabase
