Re: [HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO

2016-07-12 Thread Tom Lane
Merlin Moncure  writes:
> On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane  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


Re: [HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO

2016-07-12 Thread Merlin Moncure
On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane  wrote:
> Merlin Moncure  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


Re: [HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO

2016-07-11 Thread Tom Lane
Merlin Moncure  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