On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@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
