Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Thursday, January 24, 2013 6:51 PM Andres Freund wrote:
> On 2013-01-24 18:37:29 +0530, Amit Kapila wrote:
> > On Thursday, January 24, 2013 5:25 PM Andres Freund wrote:
> > > On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
> > > > > * The gram.y changes arround set_rest_(more|common) seem pretty
> > > > > confused
> > > > >   to me.
> > > >
> > > > >E.g. its not possible anymore to set the timezone for a
> function.
> > > >
> > > > What do you exactly mean by this part of comment.
> > >
> > > The set_rest_more production is used in FunctionSetResetClause and
> > > youve
> > > removed capabilities from it.
> >
> > set_rest_more has set_reset_common, so there should be no problem.
> >
> > set_rest_more:        /* Generic SET syntaxes: */
> >                         set_rest_common
> >                         | var_name FROM CURRENT_P
> >                                 {
> >                                         VariableSetStmt *n =
> makeNode(VariableSetStmt);
> >                                         n->kind = VAR_SET_CURRENT;
> >                                         n->name = $1;
> >                                         $$ = n;
> >                                 }
> 
> True. I still think that the split youve made isn't right as-is.

We can move FROM CURRENT and client_encoding to common part. 
Other syntax (ROLE, SESSION AUTHORIZATION, TRANSACTION SNAPSHOT) doesn't
exist in postgresql.conf and requires a transaction to set and during reload
we don't have transaction, so we should not allow them. 

With Regards,
Amit Kapila.