[BUGS] No dependency between fkey constraint and unique index

2002-09-12 Thread Kris Jurka
The following statements will fail... CREATE TABLE t1 (a int); CREATE TABLE t2 (a int references t1(a)); ERROR: UNIQUE constraint matching given keys for referenced table "t1" not found But I can do the following... CREATE TABLE t3 (a int primary key); CREATE TABLE t4 (a int references t3(a));

Re: [BUGS] Bug #759: 7.3beta1 DROP COLUMN DEPENDENCY PROBLEM

2002-09-12 Thread Tom Lane
[EMAIL PROTECTED] writes: > Been playing with the 7.3beta1 version and I've noticed a small > problem with dependency checking when dropping a column. If you have > a view which uses JOIN's to join tables then dropping a column will > fail on a dependency check, even though the column being dropp

Re: [BUGS] HELP

2002-09-12 Thread junk
Then again, dumping is probably better, and deleting the database, and then restoring it. I am just curious if it is a database problem or a table problem. If you can creat new tables that work fine, but it is a strange issue. Mark > > I would create new tables, copy the data over, then dro

Re: [BUGS] HELP

2002-09-12 Thread junk
I would create new tables, copy the data over, then drop the old tables, and rename the new tables. I have had similar problems iwht MySQL, but never with PostgreSQL. Mark > > Hi, > > I have been using PostgreSQL 7.2.2 for a while now on one of our live > machines, however all of a sudden w

Re: [BUGS] _bt_check_unique checks every row in table when doing update??

2002-09-12 Thread Bruce Momjian
Tom Lane wrote: > > (In my case, I think the call to _bt_check_unique could be > > avoided altogether since the update isn't changing any of > > the columns present in the unique key. > > It's fairly difficult for the index AM to know that; in general we don't > have access to the old tuple to ch

[BUGS] unsubscribe *

2002-09-12 Thread xayk
unsubscribe * ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [BUGS] _bt_check_unique checks every row in table when doing update??

2002-09-12 Thread Mats Lofkvist
[EMAIL PROTECTED] (Tom Lane) writes: > > But you really shouldn't need the old tuple to know this since none > > of the columns present in the unique index are 'set' by the update? > > I.e. the 'not changing the unique key part' is not data dependent, > > it is guarantied by the form of the updat

Re: [BUGS] _bt_check_unique checks every row in table when doing update??

2002-09-12 Thread Tom Lane
Mats Lofkvist <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Tom Lane) writes: >>> (In my case, I think the call to _bt_check_unique could be >>> avoided altogether since the update isn't changing any of >>> the columns present in the unique key. >> >> It's fairly difficult for the index AM to

Re: [BUGS] _bt_check_unique checks every row in table when doing update??

2002-09-12 Thread Mats Lofkvist
[EMAIL PROTECTED] (Tom Lane) writes: > Mats Lofkvist <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] (Tom Lane) writes: > >> 7.3 will be smarter about this. > > > Seems like I get the same behaviour with 7.3 beta1, updating > > the same row ~20k times and then 1k times more with profiling > >

Re: [BUGS] Bug #764: 7.3b1 : SET gives misleading error information with non-valid option name and multiple arguments

2002-09-12 Thread Tom Lane
[EMAIL PROTECTED] writes: > 7.3b1 : SET gives misleading error information with non-valid option name and >multiple arguments Fixed, thanks. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at on

Re: [BUGS] _bt_check_unique checks every row in table when doing update??

2002-09-12 Thread Tom Lane
Mats Lofkvist <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Tom Lane) writes: >> 7.3 will be smarter about this. > Seems like I get the same behaviour with 7.3 beta1, updating > the same row ~20k times and then 1k times more with profiling > enabled (and with no vacuum in between) gives: >

Re: [BUGS] HELP

2002-09-12 Thread Tom Lane
"Brendon Matthews" <[EMAIL PROTECTED]> writes: > I have been using PostgreSQL 7.2.2 for a while now on one of our live > machines, however all of a sudden with no warning, we are no longer able to > run any UPDATE statements on one of our databases. SELECT and INSERT > statements have no issues. >

Re: [BUGS] HELP

2002-09-12 Thread Rod Taylor
On Thu, 2002-09-12 at 01:13, Brendon Matthews wrote: > Hi, > > I have been using PostgreSQL 7.2.2 for a while now on one of our live > machines, however all of a sudden with no warning, we are no longer able to > run any UPDATE statements on one of our databases. SELECT and INSERT > statements ha

[BUGS] Bug #764: 7.3b1 : SET gives misleading error information with non-valid option name and multiple arguments

2002-09-12 Thread pgsql-bugs
Tim Knowles ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description 7.3b1 : SET gives misleading error information with non-valid option name and multiple arguments Long Description PostgrsqSQL 7.3b1 If you use SET with a non-valid o

Re: [BUGS] _bt_check_unique checks every row in table when doing update??

2002-09-12 Thread Mats Lofkvist
[EMAIL PROTECTED] (Tom Lane) writes: > Mats Lofkvist <[EMAIL PROTECTED]> writes: > > But when doing ~1000 updates (i.e. setting val0 and val1 with > > a where on an existing key0/key1/key2 triplet), I get this which > > seems very strange to me: > > I suppose you repeatedly updated the same row