Re: Hard-coded PUBLIC in pg_dump
| От | Tom Lane |
|---|---|
| Тема | Re: Hard-coded PUBLIC in pg_dump |
| Дата | |
| Msg-id | 15516.1038718413@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Hard-coded PUBLIC in pg_dump (Nicolai Tufar <ntufar@apb.com.tr>) |
| Ответы |
Re: Hard-coded PUBLIC in pg_dump
|
| Список | pgsql-hackers |
Nicolai Tufar <ntufar@apb.com.tr> writes:
> src/bin/pg_dump/pg_dump.c happen to have hard-coded PUBLIC role name.
As it should. I think the real problem here is the hack in gram.y:
grantee: ColId { PrivGrantee *n = makeNode(PrivGrantee); /* This
hacklets us avoid reserving PUBLIC as a keyword*/ if (strcmp($1, "public") == 0)
n->username = NULL; else n->username = $1; n->groupname =
NULL; $$ = (Node *)n; }
If the parser treated PUBLIC as an actual keyword, you'd not be having
this problem, because keywords are case-folded on an ASCII-only basis
(which is consistent with the SQL99 spec, amazingly enough).
We put in the above hack after someone complained that PUBLIC didn't use
to be a reserved word ... but considering that SQL92 clearly lists it as
a reserved word, there's not a lot of ground for that complaint to stand
on.
I'd prefer shifting PUBLIC back to the true-keyword category over any
of the other workarounds you've suggested ...
regards, tom lane
В списке pgsql-hackers по дате отправления: