Re: IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO
От | Tom Lane |
---|---|
Тема | Re: IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO |
Дата | |
Msg-id | 11633.1468361427@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO (Merlin Moncure <mmoncure@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: