Re: [RFC] Extend namespace of valid guc names

On Wed, Sep 18, 2013 at 4:26 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Hi,
>
> On 2013-09-17 16:24:34 -0400, Robert Haas wrote:
>> On Tue, Sep 17, 2013 at 10:27 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > On 2013-09-17 10:23:30 -0400, Robert Haas wrote:
>> >> What is the use case for this change?
>> >
>> > Check http://archives.postgresql.org/message-id/20130225213400.GF3849%40awork2.anarazel.de
>> > or the commit message of the patch.
>>
>> That's more or less what I figured. One thing I'm uncomfortable with
>> is that, while this is useful for extensions, what do we do when we
>> have a similar requirement for core? The proposed GUC name is of the
>> format extension.user_defined_object_name.property_name; but omitting
>> the extension name would lead to
>> user_defined_object_name.property_name, which doesn't feel good as a
>> method for naming core GUCs. The user defined object name might just
>> so happen to be an extension name.
>
> I think that ship has long since sailed. postgresql.conf has allowed
> foo.bar style GUCs via custom_variable_classes for a long time, and
> these days we don't even require that but allow them generally. Also,
> SET, postgres -c, and SELECT set_config() already don't have the
> restriction to one dot in the variable name.

It's even explained in document that a two-part name is allowed for
Customized Options at link:
http://www.postgresql.org/docs/devel/static/runtime-config-custom.html

> I think if we're going to use something like that for postgres, we'll
> have to live with the chance of breaking applications (although I don't
> think it's that big for most of the variables where I can forsee the use).
>
>> If it's not a good fit for pg_hba.conf, why is it a good fit for
>> anything else we want to do?
>
> Well, for now it's primarily there for extensions, not for core
> code. Although somebody has already asked when I'd submit the patch
> because they could use it for their patch...

I had reviewed and tested the patch.

The purpose of patch is to allow more than two-part parameter name
through postgresql.conf.

I think it's useful to allow more than two-parameter names mainly because
a) in database terminology, people are quite use to think for more
than two-part names,
for ex. any object <database_name>.<schema_name>.<object_name>
here object_name can be table_name, index_name, etc.
b) it already works in SET/set_config().

The code is fine and I had done tests for various parameters (more
than two-part) in postgresql.conf all of which works fine (Select
pg_reload_conf() and show of parameter name).
For example:

foo2.bar2.bar1 = 3
foo2.bar2.bar1 = 4
foo2.bar2.bar1.bar1 = 4
a.b._c = 4
d.e.f =on
d.e.f.g =true
d.e.f.g.h = 'abcdef'
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.y.z.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z
= 4

Apart from this, quite a few negative tests (setting invalid names)
also works fine (select pg_reload_conf() shows error on server).

We can modify the documentation for Customized Options to mention
about support for more than two-part name.

On a side note, although it doesn't have any relation with your patch,
I found some minor problems in setting of configuration during test of
this patch, so I am mentioning it here. I will look into these in
detail later:

Test-1
postgres=# select set_config('a.b.1.c','c',false);
set_config
------------
c
(1 row)

postgres=# show a.b.1.c;
ERROR: syntax error at or near ".1"
LINE 1: show a.b.1.c;

allows to set variable name which has integer, but could not see it
via show as other variables can be seen.

Test-2
test to see if longer length string are compatible in all interfaces.
set fooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.bar=1;

Behavior of set command
-------------------------
postgres=# set foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.bar=1;
NOTICE: identifier "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo" will be tru
ncated to "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo"
SET
postgres=# show foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.
bar;
foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
-----------------------------------------------------------------
1
(1 row)

Behavior when the same is set though postgresql.conf
----------------------------------------------------
postgres=# show fooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.bar;
NOTICE: identifier "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo" will be tru
ncated to "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo"
ERROR: unrecognized configuration parameter "fooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooo.bar"
postgres=#

Although variable is loaded but you cannot see it.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com