From: Michael Meskes <meskes@postgresql.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Cc: Michael Meskes <meskes@postgresql.org>
Subject: Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word
Date: Mon, 30 May 2022 15:25:16 +0200
Message-ID: <YpTFvHBWT4OlLqCP@feivel.guest.credativ.lan> (raw)
In-Reply-To: <3661437.1653855582@sss.pgh.pa.us>
References: <3661437.1653855582@sss.pgh.pa.us>
> I looked briefly at whether we could improve that situation.
> Two of the four uses of ECPGColLabelCommon in ecpg.trailer can be
> converted to the more general ECPGColLabel without difficulty,
> but trying to change either of the uses in var_type results in
> literally thousands of shift/reduce and reduce/reduce conflicts.
> This seems to be because what follows ecpgstart can be either a general
> SQL statement or an ECPGVarDeclaration (beginning with var_type),
> and bison isn't smart enough to disambiguate. I have a feeling that
> this situation could be improved with enough elbow grease, because
> plpgsql manages to solve a closely-related problem in allowing its
> assignment statements to coexist with general SQL statements. But
> I don't have the interest to tackle it personally, and anyway any
> fix would probably be more invasive than we want to put in post-beta.
Right, the reason for all this is that the part after the "exec sql" could be
either language, SQL or C. It has been like this for all those years. I do not
claim that the solution we have is the best, it's only the best I could come up
with when I implemented it. If anyone has a better way, please be my guest.
> I also wondered briefly about just changing the affected test cases,
> reasoning that breaking some ECPG applications that use "string" is
> less bad than breaking everybody else that uses "string". But type
> "string" is apparently a standard ECPG and/or INFORMIX thing, so we
> probably can't get away with that.
IIRC STRING is a normal datatype for INFORMIX and thus is implemented in ECPG
for its compatibility.
> Hence, I propose the attached, which fixes the easily-fixable
> ECPGColLabelCommon uses and adds a hard-wired special case for
> STRING to handle the var_type usage.
I'm fine with this approach.
Thanks Tom.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
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: pgsql-hackers@postgresql.org
Cc: meskes@postgresql.org, tgl@sss.pgh.pa.us, andrew@dunslane.net
Subject: Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word
In-Reply-To: <YpTFvHBWT4OlLqCP@feivel.guest.credativ.lan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox