On 2014-01-04 13:00:03 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-01-04 11:54:46 -0500, Robert Haas wrote: > >> Well, as I said before, somebody can make their own configuration > >> table and store stuff there, rather than using pg_class.reloptions. > >> As I recall, the only response to that proposal was "well, they might > >> not want to do it that way", which does not strike me as a sufficient > >> reason. > > > Well, there's some things you get by that integration: > > * Proper dependency tracking when relations are dropped & renamed > > * Sensible integration into pg_dump, with only the relevant options > > being dumped/restored on partial dump/restores > > * Caching of values, with proper cache invalidation > > If you have some settings that need to be table-specific, then > I agree that the reloptions infrastructure is a nice place to track them. > What's actually missing here is some compelling examples of such settings > for plausible extensions.
I don't know about others, but I would like to use it for bdr to configure which table is replicated where. I.e. something like bdr.replication_set=a,b,c, > (The original example was pure handwaving, as > I don't believe it's possible to build a "replication extension" with no > core-code changes. As long as you need some of those, patching in a few > more standard reloptions is hardly a deal-breaker.) Well, slony et al exist, so it's certainly possible. And even if you want to talk about logical replication, there aren't that much core changes required - and all of them have been submitted. They might not make it into 9.4 but I certainly plan to pursue things further so it's possible to stuff without patching core. > Assuming that such examples are forthcoming, though, I think my main > objection to this proposal is the "ext." prefix, which seems precisely > 100% useless, not to mention inconsistent with the naming of custom GUCs, > which the same extension might well have some of. Well, the argument is/was that it avoid conflicts with future core code adding more namespaces - like the already existing toast. prefix. If we say we can live with the possibility of such conflicts, it seems appropriate not to use ext. as a prefix. > I would suggest addressing Robert's concern about lack of error checking > by refusing to allow a custom reloption to be set unless the relevant > extension is loaded and checks it. Unlike the postgresql.conf problem, > I don't see any very good use-case for allowing an unchecked ALTER TABLE Fine with me. Greetings, Andres Freund -- Andres Freund 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
