Re: [RFC] Extend namespace of valid guc names - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [RFC] Extend namespace of valid guc names
Date
Msg-id 20130226120854.GA4405@awork2.anarazel.de
Whole thread Raw
In response to Re: [RFC] Extend namespace of valid guc names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [RFC] Extend namespace of valid guc names
List pgsql-hackers
On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > I propose loosening those restrictions to
> > a) allow repeatedly qualified names like a.b.c
> 
> If SET allows it, I guess we can allow it here.  But is a grammar change
> really all that is needed to make it work from the file?

Seems so. There's no additional validation that I could find
anywhere. And a simple test confirmed it works.

postgres=# SHOW foo.bar.blub;foo.bar.blub
--------------1
(1 row)



Just for reference, thats the grammar for SET/SHOW:

var_name:    ColId                                { $$ = $1; }        | var_name '.' ColId

> > b) allow variables to start with a digit from the second level onwards.
> 
> That seems like a seriously bad idea.  I note that SET does *not* allow
> this; furthermore it seems like a considerable weakening of our ability
> to detect silly typos in config files.  Nor did you offer a use-case
> to justify it.

The use-case I had in mind was

bdr.1.dsn = ...
bdr.2.dsn = ...
bdr.3.dsn = ...
bdr.4.dsn = ...

which is what I had used via -c. But I guess it can easy enough be
replaced by node_$i or something.

Any arguments whether we should try to validate -c SET/SHOW,
set_config() and -c the same?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq
Next
From: Andres Freund
Date:
Subject: Re: pg_xlogdump compiler warning