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
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.
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
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
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
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
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
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
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
- 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
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);
- 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
12 matches
Mail list logo
