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,

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

--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: BRIN indexes - TRAP: BadArgument
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: infinite loop in _bt_getstackbuf