Re: [PATCH] Store Extension Options - Mailing list pgsql-hackers

On Thu, Mar 13, 2014 at 10:27 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-03-13 10:24:09 -0400, Tom Lane wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>> > But security labels are a nice idea, will think about it. AFAICs there's
>> > no builtin subdivision within the label for one provider which is a bit
>> > of a shame but solvable. The biggest issue I see is that it essentially
>> > seems to require that the provider is in
>> > {shared,local}_preload_libraries? You can't restore into a server
>> > otherwise afaics?
>>
>> Well, if you want to validate the settings then you pretty much have to
>> require that in some form.
>
> If there were a CREATE SECURITY LABEL PROVIDER or something, with the
> catalog pointing to a validator function, we wouldn't necessarily...

I seriously doubt that's going to work nicely.  Now you've implicitly
introduced a dependency from every object that has a label to the
label provider.  pg_dump is going to have to restore the validator
function before it restores anything that has a label, and before that
it's going to have to restore the languages used to create those
validator functions, and those languages might themselves be labeled,
either by that provider or by other providers.

Perhaps you could untangle that mess, but I'm disinclined to try
because I can't see what real problem we're solving here.  Extension
that just provide particular functions or datatypes can be loaded on
demand, but those that change underlying system behavior need to be
loaded by the postmaster, or at least at backend startup.  We've tried
to patch around that fact with GUCs and it seems to me that we've
thoroughly destroyed validation in the process but without really
buying ourselves much.  There are five contrib modules that define
custom variables: auth_delay, auto_explain, pg_stat_statements,
sepgsql, and worker_spi.  auth_delay, worker_spi and
pg_stat_statements have to be loaded at postmaster startup time, and
you have to decide whether you want sepgsql at *initdb* time.  The
only one of those that you can possibly load on the fly into an
individual session is auto_explain, and that's probably not very
useful: if you have control of the interactive session, you might as
well just use EXPLAIN.  Maybe there are better examples outside the
core distribution, but to me it's looking like the idea that you can
add GUCs on the fly into individual sessions is a big fizz.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company