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

On Thu, Mar 13, 2014 at 10:20 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Well, I'm not going to claim that the methods that exist today are
>> perfect.  Things you can do include: (1) the table of tables approach,
>> (2) abusing comments, and perhaps (3) abusing the security label
>> machinery.  SECURITY LABEL FOR bdr ON TABLE copy_me IS 'yes, please'?
>> Only the first of those fails prong (a) of your proposed requirements,
>> and they all pass prong (b).  I'm not totally sure how well comments
>> and security labels integrate with cache invalidation.
>
> The table of table fall short of all of those, so it's pretty much
> unusable. Comments aren't usable because there's no way to coordinate
> between various users of the facility and it breaks their original
> usage. They also don't produce cache invalidations.
>
> 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.

Why do we need that?  Are we really going to have so many names here
that a simple convention that an extension providing multiple names
should prefix each one with $EXTENSION_NAME + "_" is insufficient?

> 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?

Correct.

> They currently don't seem to create invalidations on the objects they
> are set upon, maybe we should change that? There seems to be pretty
> little reason to avoid that, the frequence of change really should never
> be high enough for it to be problematic.

No objection.

>> And an interesting point is that the SECURITY LABEL feature has been
>> around since 9.1 and we've had zero complaints about the design.  This
>> either means that the design is excellent, or very few people have
>> tried to use it for anything.
>
> Without saying that its design is bad, I am pretty sure it's because
> it's basically unused.

Sure, that's my bet as well.  I think the really interesting question
here is how the dump-and-reload issue ought to be handled.  As Tom
says, it seems on the surface as though you can either require that
the provider be loaded for that, or you can accept unvalidated
settings.  Between those, my vote is for the first, because I think
that extensions are not likely to want to have to deal at runtime with
the possibility of having arbitrary values where they expect values
from a fixed list.

Basically, my feeling is that if you install an extension that adds
new table-level options, that's effectively a new version of the
database, and expecting a dump from that version to restore into a
vanilla database is about as reasonable as expecting 9.4 dumps to
restore flawlessly on 8.4.

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