On Tue, 14 May 2024 at 07:43, Michael Paquier <mich...@paquier.xyz> wrote: > > 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. > > Adding Dean in CC as the committer of faff8f8e47f, Peter E for the SQL > specification part, and an open item.
I'm sure that this wasn't intentional -- I think we just failed to notice that "param" also uses "decinteger" in the scanner. Taking a quick look, there don't appear to be any other uses of "decinteger", so at least it only affects params. Unless the spec explicitly says otherwise, I agree that we should reject this, as we used to do, and add a comment saying that it's intentionally not supported. I can't believe it would ever be useful, and the current behaviour is clearly broken. I've moved this to "Older bugs affecting stable branches", since it came in with v16. Regards, Dean