On 13 March 2014 14:03, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund <and...@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.)
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
