Re: proposal: extensible plpgsql executor - related to assertions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal: extensible plpgsql executor - related to assertions
Дата
Msg-id 18865.1388857525@sss.pgh.pa.us
обсуждение исходный текст
Ответ на proposal: extensible plpgsql executor - related to assertions  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: extensible plpgsql executor - related to assertions  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I propose a enhance the PLpgSQL_plugin struct by a new hook
>       void  (*pragma)(PLpgSQL_execstate *estate, PLpgSQL_pragma
> *pragma_stmt)

I repeat what I said a couple of days ago: it's a very bad idea to be
enabling more plpgsql plugins as long as the infrastructure can only
support one.  We need to fix that *first* before we go merrily designing
more.

I don't like the notion of a pragma statement in this form anyway,
because you've essentially made it an executable statement; usually
pragmas are compile-time things.  It appears to me that you've basically
commandeered the word "pragma" for "SET affecting a plugin's variable".
If we're inventing new callbacks for plugins, why not one that will extend
an existing statement having the right kind of semantics?  Or actually,
why would it not be better for the plugin to be using a custom GUC for
its variable?  There's a large amount of infrastructure that custom GUCs
can take advantage of, which you'd otherwise have to reinvent piece
by piece.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: truncating pg_multixact/members
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Store Extension Options