From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Erik Wienhold <ewie(at)ewie(dot)name> |
Cc: | pgsql-hackers(at)postgresql(dot)org, dean(dot)a(dot)rasheed(at)gmail(dot)com, peter(at)eisentraut(dot)org |
Subject: | Re: Underscore in positional parameters? |
Date: | 2024-05-14 06:43:25 |
Message-ID: | ZkMIDfjosMC_0Pxk@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-05-14 06:51:24 | Re: Bibliography section, some references cannot be found |
Previous Message | Peter Eisentraut | 2024-05-14 06:36:15 | Re: consider -Wmissing-variable-declarations |