> > 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 connec
> > 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 connec
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 'valu
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 r
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=#
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 agai
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 u
- 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 workarou
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: "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
> 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
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
12 matches
Mail list logo
