Re: [PATCH] Store Extension Options

On 13 March 2014 14:03, Robert Haas <robertmhaas(at)gmail(dot)com> 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.
>
> 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.)

I like that suggestion, all of it.

Perhaps change it to METADATA LABEL ?

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

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