Re: [PATCH] Store Extension Options

On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
> Andres Freund <andres@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