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 по дате отправления:

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: [COMMITTERS] Logical decoding
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Showing parallel status in \df+