Pavel Stehule writes:
> Looks so nobody has any motivation to do some deeper changes to reduce
> prohibition of reserved words. It is true, so in the real world it is not
> an issue.
Certainly anyone who's annoyed is free to do more work here.
> All tests passed without problems. I'll mark this
Hi
ne 8. 6. 2025 v 6:25 odesílatel Pavel Stehule
napsal:
> Hi
>
> I started reviewing this patch.
>
>
> so 7. 6. 2025 v 18:41 odesílatel Tom Lane napsal:
>
>> This is a rather delayed response to the discussion of bug
>> #18693 [1], in which I wrote:
>>
>> > (It's kind of annoying that "strict"
Hi
>
> 1. AFAICS, there is no real reason for STRICT to be a reserved
> rather than unreserved PL/pgSQL keyword, and for that matter not
> EXECUTE either. Making them unreserved does allow some ambiguity,
> but I don't think there's any surprises in how that ambiguity
> would be resolved; and ce
ne 8. 6. 2025 v 23:49 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Is there some description of what keywords should be reserved? If I
> > remember correctly, the scanner was changed more times, and maybe more
> > reserved keywords are not necessary.
>
> Per the comment in pl_scanner.
Pavel Stehule writes:
> Is there some description of what keywords should be reserved? If I
> remember correctly, the scanner was changed more times, and maybe more
> reserved keywords are not necessary.
Per the comment in pl_scanner.c:
* We try to avoid reserving more keywords than we have to;
Hi
>
>> 2. That "has no field" error message is flat-out wrong. The now-known
>> way to trigger it has a different cause, and what's more, we simply do
>> not know at this point whether the malleable record type has such a
>> field. So in 0002 below I just changed it to assume that the problem
Hi
I started reviewing this patch.
so 7. 6. 2025 v 18:41 odesílatel Tom Lane napsal:
> This is a rather delayed response to the discussion of bug
> #18693 [1], in which I wrote:
>
> > (It's kind of annoying that "strict" has to be double-quoted
> > in the RAISE NOTICE, especially since you get
On Sat, Apr 26, 2025, at 05:10, Tom Lane wrote:
> "Joel Jacobson" writes:
>> For years, I've felt we could benefit from introducing convenience syntax to
>> explicitly require that exactly one row is affected by a query, something
>> which
>> currently requires using a somewhat cumbersome work
"Joel Jacobson" writes:
> For years, I've felt we could benefit from introducing convenience syntax to
> explicitly require that exactly one row is affected by a query, something
> which
> currently requires using a somewhat cumbersome workaround:
> - Using `... INTO STRICT ...` for `SELECT`,
>
On Sat, Apr 26, 2025, at 06:44, Tom Lane wrote:
> This is a rather delayed response to the discussion of bug
> #18693 [1], in which I wrote:
...
> which is pretty bogus because the record *does* have a field
> named "strict". The actual problem is that STRICT is a fully
> reserved PL/pgSQL keyword
10 matches
Mail list logo
