From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Fabrizio Mello <fabriziomello(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Store Extension Options |
Date: | 2014-01-04 18:00:03 |
Message-ID: | 19152.1388858403@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-04 18:40:40 | Re: Wrong comment for bitncmp function in network.c |
Previous Message | Tom Lane | 2014-01-04 17:45:25 | Re: proposal: extensible plpgsql executor - related to assertions |