Re: Hard-coded PUBLIC in pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nicolai Tufar <ntufar(at)apb(dot)com(dot)tr>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hard-coded PUBLIC in pg_dump
Date: 2002-12-01 04:53:33
Message-ID: 15516.1038718413@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-general pgsql-hackers

Nicolai Tufar <ntufar(at)apb(dot)com(dot)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 hack lets 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

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Tom Lane 2002-12-01 04:57:26 Re: Segmentation fault while COPY in 7.3
Previous Message David Wheeler 2002-12-01 04:24:17 Re: 7.4 Wishlist

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-12-01 04:57:26 Re: Segmentation fault while COPY in 7.3
Previous Message Tom Lane 2002-12-01 04:39:42 Re: returning CHAR from C function

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-12-01 04:57:26 Re: Segmentation fault while COPY in 7.3
Previous Message Paul Ramsey 2002-12-01 04:45:28 Re: 7.4 To Do