Re: [BUGS] unable to fail over to warm standby server
Mason Hale wrote: > Given that this situation did NOT actually cause corruption, rather the > error message was mangled such that it suggested corruption, I offer this > revised suggestion for update to the documentation: > > Important note: It is critical the trigger file be created with permissions >> allowing the postgres process to remove the file. Generally this is best >> done by creating the file from the postgres user account. Failure to do so >> will prevent completion of WAL file recovery and the server from coming back >> online successfully. Ok, I've added this note to the 8.3 docs now. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5315: Unlisted keyword WINDOW
The following bug has been logged online: Bug reference: 5315 Logged by: Email address: sulf...@gmail.com PostgreSQL version: 8.4.2 Operating system: Gentoo Linux Description:Unlisted keyword WINDOW Details: According to the official documentation (http://www.postgresql.org/docs/8.4/interactive/sql-keywords-appendix.html), the SQL reserved keyword WINDOW is totally uninteresting to PostgreSQL. But in real life the parser has a different opinion. Just try this: create table a ( window integer, c varchar(20)); So, either correct the parser (is there any use for the word WINDOW in Postgres?) or the documentation. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5316: not handled error in inherit queries
The following bug has been logged online: Bug reference: 5316 Logged by: Gianfranco Frau Email address: f...@crs4.it PostgreSQL version: 8.2.11 Operating system: Ubuntu Description:not handled error in inherit queries Details: if you make this query: SELECT * from first_table where one in (SELECT one from second_table); and "second_table" don't have an "one" column, no errors are reported, but seems that the internal query returns a empty set. If you do: SELECT one from second_table; the error is correctly reported. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5308: How to disable Case sensitivity on naming identifiers
Hi everybody,
Many thanks for all your comments.
It appears that clarity is very important in a user manual. I like both
Chris and Tom 's expression.
Chris :
*"Unless double-quoted, all identifiers are folded to lower case,
making comparisons generally case insensitive. The SQL standard
mandates folding identifiers to upper case, but the consensus among
the PostgreSQL development team is that folding to lower case is
better. If double-quotes are not used ever, or are used consistently
throughout the application, this poses no compatibility problems in
terms of SQL queries."
*
Tom :
*"Key words and unquoted identifiers are case insensitive..."*
Personally, I prefer the Chris's one as it is more precise and detailed on
what PostgreSQL is doing when it processes SQL statements.
*
Now knowing that particularity, I will use PostgreSQL accordingly*.
At last, regarding SQL standards, in future releases of PostgreSQL, I would
like to remind my wish to see the suggested feature beside the "lower case
folding chosen by PostgreSQL dev. team".
Let see this example :
CREATE TABLE "EdtIndexCheck"
(
"Id" integer NOT NULL,
"SiteId" integer,
"CheckDate" timestamp without time zone,
"IndexIn" integer,
"IndexOut" integer,
"AmountBilled" double precision,
CONSTRAINT "PK_EdtIndexCheck" PRIMARY KEY ("Id")
)
When browsing tables and columns in pgadmin or psql, I see this (that is
very fine and good reading) :
EdtIndexCheck
Id
SiteId
CheckDate
IndexIn
IndexOut
AmountBilled
... and would be allowed to write queries anyway without having to use the
double-quotes like :
SELECT id, siteId, IndexIn, IndexOut, AmountBilled FROM EdtIndexCheck;
As as result, I get a friendly reading in pgadmin or psql, and have an
easier and quicker way in expressing sql statements.
I agree this feature is *not essential* but is definitely a *friendly
one*as seen in other SGBDR. This feature could be optional in other to
preserve
compatibility.
Very best regards,
Kelly
2010/2/3 Bruce Momjian
> Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Bruce Momjian escribió:
> > >> I found one place in the docs where this wasn't immediately clear, so
> I
> > >> applied the attached documentation patch.
> >
> > > I liked Tom's suggestion better, because then you don't start
> > > questioning about quoting key words or not.
> >
> > Yes, exactly, that was why I changed the ordering. I had always thought
> > that the reference to "names" of keywords was a bit off-key, too.
>
> Yea, I like Tom's wording better too.
>
> --
> Bruce Momjian http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
Re: [BUGS] BUG #5315: Unlisted keyword WINDOW
sulf...@gmail.com wrote: > > The following bug has been logged online: > > Bug reference: 5315 > Logged by: > Email address: sulf...@gmail.com > PostgreSQL version: 8.4.2 > Operating system: Gentoo Linux > Description:Unlisted keyword WINDOW > Details: > > According to the official documentation > (http://www.postgresql.org/docs/8.4/interactive/sql-keywords-appendix.html), > the SQL reserved keyword WINDOW is totally uninteresting to PostgreSQL. > > But in real life the parser has a different opinion. Just try this: > create table a ( > window integer, > c varchar(20)); > > So, either correct the parser (is there any use for the word WINDOW in > Postgres?) or the documentation. Ah, quite interesting. I grabed all the keywords in our SGML docs listed as somehow reserved in Postgres, and then ran "SELECT word FROM pg_get_keywords() WHERE catcode != 'U'" to get all the keywords from our C code, and then compared the two. The two missing keywords were OVER, and WINDOW, as you mentioned. I have applied the attached patch to CVS HEAD and 8.4.X to properly document our keywords. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/keywords.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/keywords.sgml,v retrieving revision 2.28 diff -c -c -r2.28 keywords.sgml *** doc/src/sgml/keywords.sgml 23 Dec 2009 17:41:43 - 2.28 --- doc/src/sgml/keywords.sgml 5 Feb 2010 19:34:16 - *** *** 3521,3527 OVER ! reserved reserved --- 3521,3527 OVER ! reserved (can be function or type) reserved reserved *** *** 5561,5567 WINDOW ! reserved reserved --- 5561,5567 WINDOW ! reserved reserved reserved -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
