Amit Kapila <amit.kap...@huawei.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
