Re: [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-03-13 09:17:36 -0400, Robert Haas wrote:
>> It is very true that there are other ways for extensions to manage
>> per-table options.
>
> You previously said that, but I really don't see any. Which way out
> there exists that a) doesn't leave garbage after the relation is dropped
> or renamed b) is properly dumped by pg_dump c) is properly integratable
> with cache invalidations.
>
> c) is hackable by manually sending cache invalidations from C code when
> changing the associated information, and by using a relcache callback
> for cache invalidation, but the others really aren't solveable right now
> afaics.

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.

An interesting point here is that the SECURITY LABEL functionality is
arguably exactly what is wanted here, except for the name of the
command.  Tables (and almost every other type of object in the system,
including columns, functions, etc.) can have an arbitrary number of
security labels, each of which must be managed by a separate provider,
which gets to validate those options at the time they're applied.  Of
course, the provider can simply choose to accept everything, if it
wants.  Dump-and-reload is handled by assuming that you need to have
the applicable providers present at reload time (or ignore the errors
you get when restoring the dump, or edit the dump).

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.  But I think it would be worth
considering to what extent that design (modulo the name) also meets
the requirements here.  Because it works on all object types, it's
actually quite a bit more general than this proposal. And it wouldn't
be very hard to drop the word "SECURITY" from the command and just let
objects have labels.  (We could even introduce introduce alternate
syntax, like ALTER <object-type> <object-name> SET LABEL FOR provider
TO value, if that makes things nicer, though the confusion of having
two completely different syntaxes might not be worth it.)  On the
other hand, if that design *doesn't* meet the requirements here, then
it would be good to know why.  What I think we certainly don't want to
do is invent a very similar mechanism to what already exists, but with
a slightly different set of warts.

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