Re: alter user/role CURRENT_USER
От | Adam Brightwell |
---|---|
Тема | Re: alter user/role CURRENT_USER |
Дата | |
Msg-id | CAKRt6CT2aObx-h=gtaZqLgiEsKA8dVTLsvYmEZb6W-KtdveHQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: alter user/role CURRENT_USER (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: alter user/role CURRENT_USER
Re: alter user/role CURRENT_USER |
Список | pgsql-hackers |
Kyotaro,
-Adam
--
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:
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 Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
В списке pgsql-hackers по дате отправления: