Re: [HACKERS] Hard-coded PUBLIC in pg_dump
Tom Lane wrote: 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 ... PUBLIC doesn't seem like a very common column name --- seems safe to make it reserved. We made 'value' reserved in 7.3, and that was a much more common one. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
Bruce Momjian [EMAIL PROTECTED] writes: PUBLIC doesn't seem like a very common column name --- seems safe to make it reserved. We made 'value' reserved in 7.3, and that was a much more common one. I'm still quite unhappy about 'value', and would like to look into making it unreserved again. This business does show that there are some pitfalls in that, though :-( regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
Bruce Momjian [EMAIL PROTECTED] writes: We made 'value' reserved in 7.3, and that was a much more common one. BTW, you mean current not 7.3. That patch has still got some serious problems anyway: 7.3: regression=# select value; ERROR: Attribute value not found HEAD: regression=# select value; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: We made 'value' reserved in 7.3, and that was a much more common one. BTW, you mean current not 7.3. That patch has still got some serious problems anyway: Yes, I realized later it was current. I was fixing the dbdpg regression tests, and git bitten by that, and forgot I was using current and not 7.3. 7.3: regression=# select value; ERROR: Attribute value not found HEAD: regression=# select value; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. Yow! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
On Sunday, December 1, 2002, at 10:49 AM, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: PUBLIC doesn't seem like a very common column name --- seems safe to make it reserved. We made 'value' reserved in 7.3, and that was a much more common one. I'm still quite unhappy about 'value', and would like to look into making it unreserved again. This business does show that there are some pitfalls in that, though :-( Actually, I don't think it's reserved in 7.3, only in the 7.4 development sources. Otherwise, Bricolage would fail hard, and it doesn't. So there's some time to play with this issue, I think. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
regression=# select value; ERROR: Attribute value not found HEAD: regression=# select value; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. Yow! I believe these are fixed in the patch I sent in last week. -- Rod Taylor [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
regression=# select value; ERROR: Attribute value not found HEAD: regression=# select value; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. Yow! I believe these are fixed in the patch I sent in last week. -- Rod Taylor [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[HACKERS] Hard-coded PUBLIC in pg_dump
src/bin/pg_dump/pg_dump.c happen to have hard-coded PUBLIC role name.
It completly breaks dumps when run with Turksh locale setting. In my
opinion making it lower-case would do much good and no harm. A mini
patch is given below.
On the other hand, I was thinking about wrapping all the identifiers in
dump files in single quotes. It is done in SET SESSION AUTHORIZATION
clause. Is there a reason for not doing this with table and colum names?
Regards,
Nic
*** ./src/bin/pg_dump/pg_dump.c.origSun Dec 1 03:23:56 2002
--- ./src/bin/pg_dump/pg_dump.c Sun Dec 1 03:24:48 2002
***
*** 4918,4924
* wire-in knowledge about the default public privileges for different
* kinds of objects.
*/
! appendPQExpBuffer(sql, REVOKE ALL ON %s %s FROM PUBLIC;\n,
type, name);
/* Make a working copy of acls so we can use strtok */
--- 4918,4924
* wire-in knowledge about the default public privileges for different
* kinds of objects.
*/
! appendPQExpBuffer(sql, REVOKE ALL ON %s %s FROM public;\n,
type, name);
/* Make a working copy of acls so we can use strtok */
***
*** 4980,4986
if (eqpos == tok)
{
/* Empty left-hand side means PUBLIC */
! appendPQExpBuffer(sql, PUBLIC;\n);
}
else if (strncmp(tok, group , strlen(group )) == 0)
appendPQExpBuffer(sql, GROUP %s;\n,
--- 4980,4986
if (eqpos == tok)
{
/* Empty left-hand side means PUBLIC */
! appendPQExpBuffer(sql, public;\n);
}
else if (strncmp(tok, group , strlen(group )) == 0)
appendPQExpBuffer(sql, GROUP %s;\n,
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
src/bin/pg_dump/pg_dump.c happen to have hard-coded PUBLIC role name. It completly breaks dumps when run with Turksh locale setting. In my opinion making it lower-case would do much good and no harm. A mini patch is given below. H...does putting double quotes (eg. PUBLIC) around the public word fix it? On the other hand, I was thinking about wrapping all the identifiers in dump files in single quotes. It is done in SET SESSION AUTHORIZATION clause. Is there a reason for not doing this with table and colum names? You can't put single quotes around table and column names. You need to use double quotes as they are identifiers rather than literals. Bear in mind that some improvements have been made in Postgres 7.3 with regards to quoting, so have you checked 7.3? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
- Original Message -
From: Christopher Kings-Lynne [EMAIL PROTECTED]
To: Nicolai Tufar [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, December 01, 2002 4:05 AM
Subject: Re: [HACKERS] Hard-coded PUBLIC in pg_dump
H...does putting double quotes (eg. PUBLIC) around the public word
fix
it?
No:
apb= GRANT SELECT ON TABLE maras2.esya TO PUBLIC;
ERROR: user PUBLIC does not exist
apb= GRANT SELECT ON TABLE maras2.esya TO 'PUBLIC';
ERROR: parser: parse error at or near 'PUBLIC' at character 38
apb= GRANT SELECT ON TABLE maras2.esya TO public;
GRANT
apb=
The problem here is case conversion from capital I to lower-case i.
In Turkish locale tolower('I') is not equal to 'i'. So, since public role
is lower-case internally, why would we not make it lower-case in dump file.
You can't put single quotes around table and column names. You need to
use
double quotes as they are identifiers rather than literals.
Bear in mind that some improvements have been made in Postgres 7.3 with
regards to quoting, so have you checked 7.3?
I stand corrected. It is indeed has to be double-quoted.
7.3 is quoting only SET SESSION AUTHORIZATION 'role' clause in my dump.
Possibly,
because it has been added recently. Old code does not quote anything.
Chris
Regards,
Nic.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
Nicolai Tufar [EMAIL PROTECTED] 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
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Hard-coded PUBLIC in pg_dump
- Original Message - From: Tom Lane [EMAIL PROTECTED] ... 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 ... It will work for me. But why not change PUBLIC in pg_dump output to lower-case as well? regards, tom lane Nic. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
