public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Ashutosh Sharma <[email protected]>
Cc: [email protected]
Subject: Re: ecpg: issue related to preprocessor directives
Date: Fri, 31 Jul 2020 20:06:31 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com>
References: <CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com>

Ashutosh Sharma <[email protected]> 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

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: ecpg: issue related to preprocessor directives
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox