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.) 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
