On Mon, Dec 3, 2012 at 6:38 AM, Amit Kapila <amit.kap...@huawei.com> wrote:
> On Saturday, December 01, 2012 10:00 PM Tom Lane wrote:
>> Amit Kapila <amit.kap...@huawei.com> writes:
>> > On Saturday, December 01, 2012 1:30 AM Tom Lane wrote:
>> 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.
>
> With the above suggestion also, it's not able to resolve shift/reduce
> errors.
>
> However I have tried with below changes in gram.y, it works after below
> change.
>
> %left PERSISTENT
>
> VariableResetStmt:
> RESET opt_persistent reset_common
> {
> VariableSetStmt *n = $3;
> n->is_persistent = $2;
> $$ = (Node *) n;
> }
> ;
>
> opt_persistent: PERSISTENT { $$ = TRUE; }
> | /*EMPTY*/ %prec Op { $$ = FALSE; }
> ;
>
> I am not sure if there are any problems with above change.
We usually try to avoid operator precedence declarations. They
sometimes have unforeseen consequences.
> Found one difference with the change is, the command "reset persistent"
> execution results in different errors with/without change.
>
> without change:
> unrecognized configuration parameter "persistent".
> with change:
> syntax error at or near ";"
...but this in itself doesn't seem like a problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
