On 2013-10-04 11:04:53 -0400, Robert Haas wrote:
> On Fri, Oct 4, 2013 at 10:14 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > But that's not a new problem? It already exists and isn't really
> > excerbated by this.
> ...
> > I agree that we could use some more infrastructure around configuration,
> > but I fail to understand why it's this patch's duty to deliver it. And I
> > don't see why this patch would endanger any more groundbreaking
> > improvements.
>
> You keep saying the ship has already sailed, but I think that's
> inaccurate. IMHO, we haven't committed to anything in this area as a
> matter of policy; I think the lack of a policy is demonstrated by the
> inconsistencies you point out.
Well, it is SQL exposed behaviour that exists that way since the initial
introduction of custom_variable_classes in 2004. Even if allowing
multiple levels wasn't originally intended, ISTM that thats a long time
to now declare it as a parsing bug. Especially as it doesn't actually
hurt.
> Now, if we are already committed to a policy of supporting the use
> case you're targeting with this patch, then you're right: this is just
> a trivial bug fix, and we ought to just take it for what it is and fix
> whatever other issues come up later. But if we're not committed to
> such a policy, then "support multi-level GUCs" is a new feature, and
> it's entirely right to think that, just like any other new feature, it
> needs to implement that feature completely rather than piecemeal. We
> know from experience that when certain features (e.g. hash indexes)
> are implemented incompletely, the resulting warts can remain behind
> more or less indefinitely.
Well, currently we're not committed to supporting it in postgresql.conf,
but I think there's little chance of removing it from SQL. So not
allowing it in the former doesn't buy us anything.
> As I read the thread, Amit Kapila is in favor of your proposal. Pavel
> Stehule, Alvaro Herrera, and I all questioned whether multi-level GUCs
> were a good idea; at least 2 out of the 3 of us favor not committing
> the patch out of uncertainty that we wish to be on the hook to support
> such usages. Andrew Dunstan and Tom Lane agreed that the current
> behavior was inconsistent but neither clearly endorsed relaxing the
> checks in guc-file.l; in fact, Tom suggested tightening up SET
> instead.
That's slightly different than how I read it ;). Tom seems to argue
against restricting SET further (28392.1378476803@sss.pgh.pa.us).
But yes, I certainly haven't convinced everyone.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
