On Saturday, December 01, 2012 10:00 PM Tom Lane wrote:
> Amit Kapila <amit.kapila@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*/
%precOp { $$ = FALSE; } ;
I am not sure if there are any problems with above change.
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 ";"
As per your yesterday's mail, it seems to me you are disinclined to have
RESET PERSISTENT syntax.
Can we conclude on that point? My only worry is user will have no way to
delete the entry from .auto.conf file.
Suggestions?
With Regards,
Amit Kapila.
