Re: [RFC] Extend namespace of valid guc names
От | Amit Kapila |
---|---|
Тема | Re: [RFC] Extend namespace of valid guc names |
Дата | |
Msg-id | CAA4eK1KqgbxGMetB_d2AT68emAH96dDAvwpnEvjiDW7j5AsAuw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [RFC] Extend namespace of valid guc names (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [RFC] Extend namespace of valid guc names
(Andres Freund <andres@2ndquadrant.com>)
|
Список | pgsql-hackers |
On Wed, Sep 18, 2013 at 4:26 AM, Andres Freund <andres@2ndquadrant.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@2ndquadrant.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
В списке pgsql-hackers по дате отправления:
Следующее
От: Jeevan ChalkeДата:
Сообщение: Re: proposal: simple date constructor from numeric values