Re: Underscore in positional parameters? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Underscore in positional parameters?
Date
Msg-id ZkMIDfjosMC_0Pxk@paquier.xyz
Whole thread Raw
In response to Underscore in positional parameters?  (Erik Wienhold <ewie@ewie.name>)
Responses Re: Underscore in positional parameters?
List pgsql-hackers
On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
> the parameter number with atol which stops at the underscore.  That's a
> regression in faff8f8e47f.  Before that commit, $1_2 resulted in
> "ERROR: trailing junk after parameter".

Indeed, the behavior of HEAD is confusing.  "1_2" means 12 as a
constant in a query, not 1, but HEAD implies 1 in the context of
PREPARE here.

> I can't tell which fix is the way to go: (1) accept underscores without
> using atol, or (2) just forbid underscores.  Any ideas?

Does the SQL specification tell anything about the way parameters
should be marked?  Not everything out there uses dollar-marked
parameters, so I guess that the answer to my question is no.  My take
is all these cases should be rejected for params, only apply to
numeric and integer constants in the queries.

> atol can be replaced with pg_strtoint32_safe to handle the underscores.
> This also avoids atol's undefined behavior on overflows.  AFAICT,
> positional parameters are not part of the SQL standard, so nothing
> prevents us from accepting underscores here as well.  The attached patch
> does that and also adds a test case.
>
> But reverting {param} to its old form to forbid underscores also makes
> sense.  That is:
>
>     param            \${decdigit}+
>     param_junk        \${decdigit}+{ident_start}
>
> It seems very unlikely that anybody uses that many parameters and still
> cares about readability to use underscores.  But maybe users simply
> expect that underscores are valid here as well.

Adding Dean in CC as the committer of faff8f8e47f, Peter E for the SQL
specification part, and an open item.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: consider -Wmissing-variable-declarations
Next
From: Daniel Gustafsson
Date:
Subject: Re: Bibliography section, some references cannot be found