On 2013-10-04 11:04:53 -0400, Robert Haas wrote: > On Fri, Oct 4, 2013 at 10:14 AM, Andres Freund <and...@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.1378476...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
