Re: proposal: extensible plpgsql executor - related to assertions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <pgmail(at)joh(dot)to>, Josh Berkus <josh(at)agliodbs(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: proposal: extensible plpgsql executor - related to assertions
Date: 2014-01-04 17:45:25
Message-ID: 18865.1388857525@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-04 18:00:03 Re: [PATCH] Store Extension Options
Previous Message Tom Lane 2014-01-04 17:38:03 Re: truncating pg_multixact/members