Re: [BUGS] BUG #1502: hash_seq_search might return removed entry

2005-02-27 Thread Thomas Hallgren
Tom Lane wrote: Thomas Hallgren <[EMAIL PROTECTED]> writes: Would such a patch be accepted? Seems like a brute-force solution. I'd look first at whether AtCommit_Portals could just restart its hashtable scan after each deletion; if that seems too inefficient, modify the hash table entries

Re: [BUGS] BUG #1497: Default permissions allow any user to create objects in any database

2005-02-27 Thread Barry Brown
First paragraph of section 17.4 (Privileges): "When a database object is created, it is assigned an owner. By default, only an owner (or a superuser) can do anything with the object. In order to allow other users to use it, privileges must be granted." To me, that paragraphs says that only

[BUGS] BUG #1507: CREATE RULE commands atomicity

2005-02-27 Thread Alexis Wilke
The following bug has been logged online: Bug reference: 1507 Logged by: Alexis Wilke Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: Linux (not relevant) Description:CREATE RULE commands atomicity Details: I read the page about CREATE R

[BUGS] BUG #1508: Install problem and workaround

2005-02-27 Thread Edward Jones
The following bug has been logged online: Bug reference: 1508 Logged by: Edward Jones Email address: [EMAIL PROTECTED] PostgreSQL version: 8.01 Operating system: XP Professional Description:Install problem and workaround Details: Initial attempts at installing Postg

[BUGS] select clause not according to SQL standard

2005-02-27 Thread Klaus Ita
hi all! i am using version 7.4.7/Debian of postgres. as far as i understand the standard, the following situation should not be possible. neither is it stated in the manual that the select is not conforming to the standard. i have the following data: table L: LNR ORT LCODE MENGE L1

[BUGS] select clause not according to SQL standard

2005-02-27 Thread Klaus Ita
hi all! sorry if you are recieving this twice, i amm too stupid to file a simple bugreport (3rd!!! try already) i am using version 7.4.7/Debian of postgres. as far as i understand the standard, the following situation should not be possible. neither is it stated in the manual that the select is

Re: [BUGS] BUG #1397: busy-loop hang on web server

2005-02-27 Thread Chris Jones
For what it's worth, this bug doesn't appear at all now that I've upgraded to 8.0.1. Whatever bug tracking system you folks are using, feel free to close this one. Chris -- Chris Jones [EMAIL PROTECTED]www.cjones.org PGP ID 5AFDD40A ---(

[BUGS] BUG #1509: odbc driver

2005-02-27 Thread rafal
The following bug has been logged online: Bug reference: 1509 Logged by: rafal Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: windows 2003 server Description:odbc driver Details: I have had installed version 7.3 of PostgreSQL server and

Re: [BUGS] BUG #1470: Boolean expression index not used when it could be

2005-02-27 Thread Sergey Koshcheyev
Tom Lane wrote: "Sergey Koshcheyev" <[EMAIL PROTECTED]> writes: I'm trying to optimize "is null" queries, since PgSQL doesn't index null values. I have found that creating an expression index on (column is null) could work, but it doesn't get used unless the index expression is part of a comparison

Re: [BUGS] BUG #1502: hash_seq_search might return removed entry

2005-02-27 Thread Tom Lane
Thomas Hallgren <[EMAIL PROTECTED]> writes: > Would such a patch be accepted? Seems like a brute-force solution. I'd look first at whether AtCommit_Portals could just restart its hashtable scan after each deletion; if that seems too inefficient, modify the hash table entries themselves to carry a

Re: [BUGS] BUG #1510: Indexes on boolean fields

2005-02-27 Thread Tom Lane
"Sergey Koshcheyev" <[EMAIL PROTECTED]> writes: > this is an addition to my bug report #1470. I have found that if I have a > boolean column and create an index on it, it doesn't get picked up for > conditions like "WHERE column" or "WHERE NOT column", only "WHERE column = > true" or "WHERE column

[BUGS] BUG #1510: Indexes on boolean fields

2005-02-27 Thread Sergey Koshcheyev
The following bug has been logged online: Bug reference: 1510 Logged by: Sergey Koshcheyev Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: Debian Linux Description:Indexes on boolean fields Details: Hi, this is an addition to my bug rep

Re: [BUGS] PGPASSWORD

2005-02-27 Thread Oliver Jowett
Andreas Pflug wrote: Oliver Jowett wrote: postgresbugs wrote: The functionality provided by PGPASSWORD should not be removed unless there is a functionality other than .pgpass, which is fine for some uses and not for others, that will provide similar functionality. That could be psql and pg_dump

Re: [BUGS] PGPASSWORD

2005-02-27 Thread Andreas Pflug
Oliver Jowett wrote: postgresbugs wrote: The functionality provided by PGPASSWORD should not be removed unless there is a functionality other than .pgpass, which is fine for some uses and not for others, that will provide similar functionality. That could be psql and pg_dump and the like accepti

Re: [BUGS] BUG #1502: hash_seq_search might return removed entry

2005-02-27 Thread Thomas Hallgren
Bruce Momjian wrote: Thomas Hallgren wrote: Tom Lane wrote: "Thomas" <[EMAIL PROTECTED]> writes: The hash_seq_search keeps track of what element that it should return next in a HASH_SEQ_STATUS struct when it peruses a bucket. Removing that element from the table won't change anything since the s