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. (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.) 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. I think that custom reloptions should just have names like "extension_name.option_name", the same as custom GUCs do. We have enough experience now with custom GUCs that I don't think it's unreasonable to model the behavior of custom reloptions on them as closely as possible. 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 to occur. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers