[BUGS] inherited tables failure
Laszlo Csite ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description inherited tables failure Long Description We have two tables inherited one from the other one. If you try to insert from the parent into the child by an "INSERT INTO" statement then the record is inserted into the child but into the parent too! Therefore in the parent duplicated rows appear. The other bug is if you delete a row from the parent then it erases from the child too. see the illustration below. Sample Code create table try (col1 int4); create table try1 () inherits (try); insert into try (col1) values (15); select * from try1; --> you get 0 row select * from try; --->you get 1 row insert into try1 select * from try; --> the answer is 1 row is inserted into try1 select * from try1; --> you get 1 row select * from try; --->you get 2 row !!! <-That's wrong delete from try; select * from try1; --> you get 0 row !!! <-That's wrong select * from try; --->you get 0 row No file was uploaded with this report ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] inherited tables failure
On Thu, 16 Aug 2001 [EMAIL PROTECTED] wrote: > Laszlo Csite ([EMAIL PROTECTED]) reports a bug with a severity of 1 > The lower the number the more severe it is. > > Short Description > inherited tables failure > > Long Description > We have two tables inherited one from the other one. If you try to > insert from the parent into the child by an "INSERT INTO" statement > then the record is inserted into the child but into the parent too! > Therefore in the parent duplicated rows appear. > > The other bug is if you delete a row from the parent then it erases > from the child too. see the illustration below. > create table try (col1 int4); > create table try1 () inherits (try); > insert into try (col1) values (15); > select * from try1; --> you get 0 row > select * from try; --->you get 1 row > insert into try1 select * from try; --> the answer is 1 row is inserted into try1 > > select * from try1; --> you get 1 row > select * from try; --->you get 2 row !!! <-That's wrong No, that's the intended behavior. The default behavior as of 7.1 (I believe) is that sql queries occur across inheritance trees. So the latter is select from try and any subtables. If you only want try, use ONLY (select * from ONLY try). There's only one copy of the row, however. > delete from try; > select * from try1; --> you get 0 row !!! <-That's wrong > select * from try; --->you get 0 row No, that's also intended. As above, delete from try means delete from try and any subtables and only means delete from only that table. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] inherited tables failure
[EMAIL PROTECTED] writes: > Long Description > We have two tables inherited one from the other one. If you try to insert from the >parent into the child by an "INSERT INTO" statement then the record is inserted into >the child but into the parent too! Therefore in the parent duplicated rows appear. > The other bug is if you delete a row from the parent then it erases from the child >too. see the illustration below. This is not a bug; it's the way things are supposed to work in 7.1. "*" is now the default behavior. Use ONLY if you want to restrict scans or updates to the parent table. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Using nulls with earthdistance operator crashes backend (patch)
Mark Stosberg <[EMAIL PROTECTED]> writes: > Here's a patch using "isstrict": Oh, there's just the one function? Sorry for making you go to the work of submitting a patch ;-) ... I thought there'd be more to it. Will apply. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
