Re: [HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO
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
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
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
[HACKERS] 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