On Sun, Dec 19, 2010 at 5:41 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > ... users IMO should not be concerned with custom_variable_classes at > all. The only users that know about it have already written an extension > in C.
I agree with the goal. > Now, I can see this mechanism evolving in several directions. Either we > remove it entirely, or we add a list ok known custom_variable_classes > and SINVAL support for it so that as soon as the setting changes, all > concurrent backends know about it, and so that you have a catalog cache > to walk through rather than a real catalog to seqscan and backend init. It'd certainly be better to jigger this so that we do syscache lookups for each CVC that is actually needed rather than seq-scanning the whole catalog. Even that is going to be slower than the present method, but at least the overhead is proportional to the number of CVCs you're actually using - and in particular, it's zero if no CVCs are in use, which must be regarded as one of the common cases. But I'm not sure that by itself is enough to save this proposal. Right now, custom_variable_classes is a server-wide setting. But what happens if you install an extension into database A and then set a related configuration parameter in postgresql.conf? When connecting to database A, things are OK. But as soon as someone tries to connect to database B, the wheels come off. Either the connection fails (which seems pretty undesirable) or it works but we don't process those GUCs (which is outright broken if the extension requires that every backend see the same value - think for example of a PGC_POSTMASTER option controlling shared memory allocation). My gut feeling at the moment is that, given enough time and thought, there may well be a way to work through all of this and come up with a design that works. But we're pretty tight on time right now, and even if we had a perfect design today, I think I'd still argue for putting it in a separate patch. I think that the value of extensions is first and foremost that they can simplify installing, removing, dumping, and restoring extensions. I'd rather see us nail that, and then worry about custom_variable_classes as a separate issue, likely for 9.2 or beyond. Otherwise, I am afraid (as I am for all the big patches we have in the works at this point) that we may end up with nothing. That would be a real shame. -- 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
