Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-12-01 16:30:09
Message-ID: 15483.1354379409@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> On Saturday, December 01, 2012 1:30 AM Tom Lane wrote:
>> But having said that, it's not apparent to me why inventing SET
>> PERSISTENT should require reserving PERSISTENT.

> The problem is due to RESET PERSISTENT configuration_variable Syntax.
> I think the reason is that configuration_variable name can also be
> persistent, so its not able to resolve.

Well, that certainly looks like it should not be very difficult.

The secret to getting bison to do what you want is to not ask it to
make a shift/reduce decision too early.  In this case I imagine you
are trying to do something like

	RESET opt_persistent var_name

which cannot work if "persistent" could be a var_name, because bison
has to decide whether to reduce opt_persistent to PERSISTENT or empty
before it can see if there's anything after the var_name.  So the fix
is to not use an opt_persistent production, but spell out both
alternatives:

	RESET var_name

	RESET PERSISTENT var_name

Now bison doesn't have to choose what to reduce until it can see the end
of the statement; that is, once it's scanned RESET and PERSISTENT, the
choice of whether to treat PERSISTENT as a var_name can be conditional
on whether the next token is a name or EOL.

But even if we can't make that work, it's not grounds for reserving
PERSISTENT.  Instead I'd be inclined to forget about "RESET PERSISTENT"
syntax and use, say, SET PERSISTENT var_name TO DEFAULT to mean that.
(BTW, I wonder what behavior that syntax has now in your patch.)

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2012-12-01 16:36:20
Subject: Re: --single-transaction hack to pg_upgrade does not work
Previous:From: Bruce MomjianDate: 2012-12-01 16:16:01
Subject: Re: --single-transaction hack to pg_upgrade does not work

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group