From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Sharma <ashu.coek88@gmail.com>
cc: pgsql-interfaces@postgresql.org
Subject: Re: ecpg: issue related to preprocessor directives
In-reply-to: 
 <CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com>
References: 
 <CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com>
Comments: In-reply-to Ashutosh Sharma <ashu.coek88@gmail.com>
	message dated "Fri, 31 Jul 2020 10:46:00 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1853326.1596240391.1@sss.pgh.pa.us>
Date: Fri, 31 Jul 2020 20:06:31 -0400
Message-ID: <1853327.1596240391@sss.pgh.pa.us>
Precedence: bulk

Ashutosh Sharma <ashu.coek88@gmail.com> writes:
> When the following ecpg program having preprocessor directives is compiled,
> the output produced is not correct.
> ...
> As seen from above output, both exec sql ifdef and exec sql else block got
> compiled which is wrong. If the above output is further compiled using gcc
> compiler, the compilation would fail.

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.

			regards, tom lane