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
signature.asc
Description: PGP signature