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

From Dean Rasheed
Subject Re: Underscore in positional parameters?
Date
Msg-id CAEZATCWY=JDqen56qSZRHn1QsYYjuVBBaqSCQrB6xOpHz+=L1w@mail.gmail.com
Whole thread Raw
In response to Re: Underscore in positional parameters?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Underscore in positional parameters?
Re: Underscore in positional parameters?
List pgsql-hackers
On Tue, 14 May 2024 at 07:43, Michael Paquier <michael@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



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] Fix bug when calling strncmp in check_authmethod_valid
Next
From: Alvaro Herrera
Date:
Subject: Re: cataloguing NOT NULL constraints