Re: [RFC] Extend namespace of valid guc names

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.

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.

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.  Not one person argued that multi-level GUCs were already a
supported feature and that this patch was just plugging a gap in that
feature; the documentation also disagrees with that interpretation.
So I just don't think we have consensus that this is already the
policy or that it is a policy we should adopt.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company