MIME-Version: 1.0
References: 
 <CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com>
 <1853327.1596240391@sss.pgh.pa.us> <1925404.1596292531@sss.pgh.pa.us>
In-Reply-To: <1925404.1596292531@sss.pgh.pa.us>
From: Ashutosh Sharma <ashu.coek88@gmail.com>
Date: Mon, 3 Aug 2020 16:09:10 +0530
Message-ID: 
 <CAE9k0PmE2JQKz8wp_aiixL=Cw=dgpH1mW-NQD6nOFhHqo+wyeg@mail.gmail.com>
Subject: Re: ecpg: issue related to preprocessor directives
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org, Michael Meskes <meskes@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

Thanks for the patch. I've spent quite some time reviewing it and the
changes look good to me.  It looks very neat and is also
crystal-clear.

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com

On Sat, Aug 1, 2020 at 8:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > Looking at pgc.l, it seems that 'elif' is treated as though it were
> > 'endif' followed by 'ifdef', which of course completely loses the
> > expected property that a previous successful branch would keep the
> > elif branch from being expanded.
> > While this doesn't look terribly hard to fix, I'm a little disturbed
> > by the fact that the existing semantics seem to date back to 1999
> > (b57b0e044).  We're probably risking breaking existing app code if
> > we change it.  I think we *should* change it, of course, but I'm kind
> > of inclined not to back-patch.
>
> Here's a proposed patch, which also clarifies the documentation,
> which seemed a bit confused/misleading to me.
>
> As stated, I'm not sure it's wise to back-patch this aggressively
> ... but maybe it'd be okay to squeeze it into v13?
>
>                         regards, tom lane
>