Re: proposal: extensible plpgsql executor - related to assertions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal: extensible plpgsql executor - related to assertions
Date
Msg-id 18865.1388857525@sss.pgh.pa.us
Whole thread Raw
In response to proposal: extensible plpgsql executor - related to assertions  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: extensible plpgsql executor - related to assertions
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: truncating pg_multixact/members
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Store Extension Options