Обсуждение: 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

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

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

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