IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO
Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
SCHEMA as INTO variable. I estimate this to be minor oversight in
pl/pgsql parsing with respect to the introduction of this statement.
Assuming it's easily fixed, would a patch to fix pl/pgsql parsing be
accepted?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
SCHEMA as INTO variable.
Ugh, that's definitely a bug.
I estimate this to be minor oversight in
pl/pgsql parsing with respect to the introduction of this statement.
While we can certainly hack it by something along the lines of not
recognizing INTO when the first token was IMPORT, the whole thing
seems awfully messy and fragile. And it will certainly break again
the next time somebody decides that INTO is le mot juste in some new
SQL command. I wish we could think of a safer, more future-proof
solution. I have no idea what that would be, though, short of
deprecating INTO altogether.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Merlin Moncure <mmoncure@gmail.com> writes:
Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
SCHEMA as INTO variable.Ugh, that's definitely a bug.
I estimate this to be minor oversight in
pl/pgsql parsing with respect to the introduction of this statement.While we can certainly hack it by something along the lines of not
recognizing INTO when the first token was IMPORT, the whole thing
seems awfully messy and fragile. And it will certainly break again
the next time somebody decides that INTO is le mot juste in some new
SQL command. I wish we could think of a safer, more future-proof
solution. I have no idea what that would be, though, short of
deprecating INTO altogether.
This is a natural consequence of having two
almost-but-not-quite-the-same grammars handing the same shared
language. There are a similar set of annoyances compiling C with a
C++ compiler as we all know. In a perfect world, SQL procedural
extensions would be a proper superset and we'd have *one* grammar
handling everything. Among other niceties this would make moving
forward with stored procedures a much simpler discussion. Well, C'est
la vie :-D.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
While we can certainly hack it by something along the lines of not
recognizing INTO when the first token was IMPORT, the whole thing
seems awfully messy and fragile. And it will certainly break again
the next time somebody decides that INTO is le mot juste in some new
SQL command. I wish we could think of a safer, more future-proof
solution. I have no idea what that would be, though, short of
deprecating INTO altogether.
This is a natural consequence of having two
almost-but-not-quite-the-same grammars handing the same shared
language. There are a similar set of annoyances compiling C with a
C++ compiler as we all know. In a perfect world, SQL procedural
extensions would be a proper superset and we'd have *one* grammar
handling everything. Among other niceties this would make moving
forward with stored procedures a much simpler discussion. Well, C'est
la vie :-D.
Yeah, I was just belly-aching ;-). Not much choice in the short term.
Fix pushed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers