From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Erik Wienhold <ewie(at)ewie(dot)name>, pgsql-hackers(at)postgresql(dot)org, peter(at)eisentraut(dot)org |
Subject: | Re: Underscore in positional parameters? |
Date: | 2024-05-14 14:40:39 |
Message-ID: | 1089460.1715697639@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Tue, 14 May 2024 at 07:43, Michael Paquier <michael(at)paquier(dot)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".
> 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.
+1, let's put this back the way it was.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-05-14 14:42:04 | Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s). |
Previous Message | Tom Lane | 2024-05-14 14:38:31 | Re: Why is citext/regress failing on hamerkop? |