Re: Underscore in positional parameters?

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