From: | Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "Marti R(dot)" <marti(at)juffo(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: alter user/role CURRENT_USER |
Date: | 2014-10-30 18:24:14 |
Message-ID: | CAKRt6CT2aObx-h=gtaZqLgiEsKA8dVTLsvYmEZb6W-KtdveHQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/15516.1038718413@sss.pgh.pa.us
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 - adam(dot)brightwell(at)crunchydatasolutions(dot)com
Database Engineer - www.crunchydatasolutions.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-10-30 18:35:50 | Re: infinite loop in _bt_getstackbuf |
Previous Message | Robert Haas | 2014-10-30 17:56:22 | Re: BRIN indexes - TRAP: BadArgument |