* Adam Brightwell (adam.brightwell@crunchydatasolutions.com) wrote:
> > | RoleId_or_curruser: RoleId { $$ = $1; }
> > | | CURRENT_USER { $$ = "\x00\x01";};
[...]
> > This is ugly but needs no additional struct member or special
> > logics. (Macros could make them look better.)
>
> Yeah, that's pretty ugly. I think Alvaro's recommendation of having the
> production return a node with a name or flag is the better approach.
That's more than just 'ugly', in my view. I don't think there's any
reason to avoid making this into a node with a field that can be set to
indicate it's something special if we're going to support this.
The other idea which comes to mind is- could we try to actually resolve
what the 'right' answer is here, instead of setting a special value and
then having to detect and fix it later? Perhaps have a Oid+Rolename
structure and then fill in the Oid w/ GetUserId(), if we're called with
CURRENT_USER, and otherwise just populate the Rolename field and have
code later which fills in the Oid if it's InvalidOid.
> > Please let me know the reason to avoid registering new keyword
> > making the word unusable as an literal identifier, if any?
We really don't want to introduce new keywords without very good reason,
and adding to the list of "can't be used even if quoted" is all but
completely forbidden.
Thanks,
Stephen