Re: [PATCH] Store Extension Options

On 2014-03-13 10:03:03 -0400, Robert Haas wrote:
> On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund <andres(at)2ndquadrant(dot)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.

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

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.

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

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services