Why not just drop the "references" clause? I mean, the point of having transactions is to guarantee integrity within a transaction, if you're not going to have that, why even bother with the clause?
Most of my databases don't even user "references", just because I like the flexibility, and I have multitable keys (keys that can refer to rows from multiple tables). Jon On Mon, 28 Jul 2003, Dmitry Tkach wrote: > kay-uwe.genz wrote: > > >Hi @ all, > > > >i've a little problem with two tables and FOREIGN KEYs. I've read about > >this long time ago, but didn't remember me where. Well, I hope you can > >help me. > > > >I've create two TABLEs "counties" and "cities". "Countries" have a row > >"capital" is REFERENCEd "cities". "cities" have a row country > >REFERENCEd "countries", where a save the country the city is placed. > > > >And now PG couldn't create the TABLEs, because the referenced table > >doesn't exists in time of creation. Is there another method of creating > >than the ALTER TABLE the first table after the second is living? > > > No. But what's wrong with ALTER TABLE? > > > > >Second question. Is there a method of INSERT INTO both tables VALUES > >without group them in the same Transaction? > > > > > No (assuming, that you are talking about inserting a new country and a > capital at the same time, and that the country's capital column cannot > be null). > But what's wrong with transactions? > > Dima > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
