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

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Showing parallel status in \df+
Следующее
От: AMatveev@bitec.ru
Дата:
Сообщение: One process per session lack of sharing