From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Jumble Query with COERCE_SQL_SYNTAX |
Date: | 2022-03-30 03:23:45 |
Message-ID: | 20220330032345.kdbamvqeophwzvqe@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Tue, Mar 29, 2022 at 03:52:57PM +0300, Yura Sokolov wrote:
>
> v14 introduced the way to get original text for some kind of expressions
> using new 'funcformat' - COERCE_SQL_SYNTAX:
> - EXTRACT(part from timestamp)
> - (text IS [form] NORMALIZED)
> and others.
>
> Mentioned EXTRACT and NORMALIZED statements has parts, that are not
> usual arguments but some kind of syntax. At least, there is no way to:
>
> PREPARE a(text) as select extract($1 from now());
>
> But JumbleExpr doesn't distinguish it and marks this argument as a
> variable constant, ie remembers it in 'clocations'.
>
> I believe such "non-variable constant" should not be jumbled as
> replaceable thing.
Yeah, the problem is really that those are some form of sublanguage inside SQL,
which is always a mess :(
It's probably an implementation detail that we treat those as syntactic sugar
for plain function calls, but since that's what we're doing I don't think it's
really sensible to change that. For instance, for the query jumbler using this
query or "select pg_catalog.extract($1, now())" are identical, and that form
can be prepared. Maybe it would make sense to allow a parameter for the
EXTRACT(x FROM y), since we're already allowing a non-standard form with
plain string literal? The story is a bit different for NORMALIZED though.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2022-03-30 03:38:43 | Re: Assert in pageinspect with NULL pages |
Previous Message | Peter Geoghegan | 2022-03-30 03:08:32 | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |