Erik Wienhold writes:
> On 2024-04-13 00:20 +0200, Tom Lane wrote:
>> I'm not here to defend plpgsql's factorization ;-). However, it
>> doesn't really have a parser of its own, at least not for expressions,
>> so I'm not sure how your suggestion could be made to work.
> Not a suggestion. Just
On 2024-04-13 00:20 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > I'm surprised that the lexer handles compound tokens. I'd expect to
> > find that in the parser, especially because of using the context-aware
> > plpgsql_ns_lookup to determine if we have a T_DATUM or T_{WORD,CWORD}.
>
> I'm
Erik Wienhold writes:
> I'm surprised that the lexer handles compound tokens. I'd expect to
> find that in the parser, especially because of using the context-aware
> plpgsql_ns_lookup to determine if we have a T_DATUM or T_{WORD,CWORD}.
I'm not here to defend plpgsql's factorization ;-). Howev
On 2024-04-09 00:54 +0200, Tom Lane wrote:
> I poked at this and found that the failures occur when the patched
> code decides to trim an expression like "_r.v" to just "_r", naturally
> breaking the semantics completely. That happens because when
> plpgsql_yylex recognizes a compound token, it do
út 9. 4. 2024 v 0:55 odesílatel Tom Lane napsal:
> Erik Wienhold writes:
> > On 2024-04-07 06:33 +0200, Tom Lane wrote:
> >> I suspect it'd be much more robust if we could remove the comment from
> >> the expr->query string. No idea how hard that is.
>
> > I slept on it and I think this can be
Erik Wienhold writes:
> On 2024-04-07 06:33 +0200, Tom Lane wrote:
>> I suspect it'd be much more robust if we could remove the comment from
>> the expr->query string. No idea how hard that is.
> I slept on it and I think this can be fixed by tracking the end of the
> last token before THEN and
I wrote:
> Attached v2 tries to do that.
Hit send too soon. Attached now.
--
Erik
>From 23a20a410dc92946141b6c6fa5100473eac482cf Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Sat, 6 Apr 2024 22:36:54 +0200
Subject: [PATCH v2] plpgsql: accept trailing line comment in CASE WHEN
Expression
On 2024-04-07 06:33 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > I'm surprised that the comment is not skipped by the scanner at this
> > point. Maybe because the parser just reads the raw expression between
> > WHEN and THEN with plpgsql_append_source_text via read_sql_construct.
>
> > Ho
Erik Wienhold writes:
> On 2024-04-06 20:14 +0200, Michal Bartak wrote:
>> The issue described bellow exists in postgresql ver 16.2 (found in some
>> previous major versions)
> Can confirm also on master.
I'm sure it's been there a while :-(
> I'm surprised that the comment is not skipped by th
On 2024-04-06 20:14 +0200, Michal Bartak wrote:
> The issue described bellow exists in postgresql ver 16.2 (found in some
> previous major versions)
Can confirm also on master.
> The documentation defines a comment as:
>
> > A comment is a sequence of characters beginning with double dashes and
Hello all
The issue described bellow exists in postgresql ver 16.2 (found in some
previous major versions)
The documentation defines a comment as:
> A comment is a sequence of characters beginning with double dashes and
> extending to the end of the line
When using such a comment within CASE c
11 matches
Mail list logo
