Kyotaro,
Zero-length identifiers are rejected in scanner so RoleId cannot
> be a valid pointer to a zero-length string. (NULL is used as
> PUBLIC in auth_ident)
>
> | postgres=# create role "";
> | ERROR: zero-length delimited identifier at or near """"
> | postgres=# create role U&"\00";
> | ERROR: invalid Unicode escape value at or near "\00""
>
Err... what? I'm not sure what you are getting at here? Why would we ever
have/want a zero-length identifier for a RoleId? Seems to me that anything
requiring a RoleId should be explicit.
As a dirty and quick hack we can use some integer values prfixed
> by single zero byte to represent special roles such as
> CURRENT_USER.
>
> | RoleId_or_curruser: RoleId { $$ = $1; }
> | | CURRENT_USER { $$ = "\x00\x01";};
> ....
> | Oid ResolveRoleId(const char *name, bool missing_ok)
> | {
> | Oid roleid;
> |
> | if (name[0] == 0 && name[1] == 1)
> | roleid = GetUserId();
>
> 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.
| /* This hack lets us avoid reserving PUBLIC as a keyword*/
> | if (strcmp($1, "public") == 0)
>
> Please let me know the reason to avoid registering new keyword
> making the word unusable as an literal identifier, if any?
>
FWIW, I found the following in the archives:
http://www.postgresql.org/message-id/[email protected]
Now this is from 2002 and it appears it wasn't necessary to change at the
time, but I haven't yet found anything else related (it's a big archive).
Though, as I understand it, PUBLIC is now non-reserved as of SQL:2011 which
might make a compelling argument to leave it as is?
-Adam
--
Adam Brightwell - [email protected]
Database Engineer - www.crunchydatasolutions.com
