Re: Incomprehensible behaviour of a foreign key.
От | Kathy Zhu |
---|---|
Тема | Re: Incomprehensible behaviour of a foreign key. |
Дата | |
Msg-id | 200307211610.h6LGAmc19468@amon.Central.Sun.COM обсуждение исходный текст |
Ответ на | Incomprehensible behaviour of a foreign key. ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Ответы |
Re: Incomprehensible behaviour of a foreign key.
|
Список | pgsql-general |
How can you have two tables with the same name in one database ?? How do you differentiate them when you use it in queries ?? > X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org > Date: Sun, 20 Jul 2003 21:23:12 +0100 (BST) > From: "Nigel J. Andrews" <nandrews@investsystems.co.uk> > X-Sender: nandrews@ponder.fairway2k.co.uk > To: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Incomprehensible behaviour of a foreign key. > X-Virus-Scanned: by amavisd-new at postgresql.org > > > > On Sun, 20 Jul 2003, Nigel J. Andrews wrote: > > > Blah, blah, blah. > > > > Further hair pulling and trying many many things and I finally discovered why > this foreign key constraint problem was so weird, I looked up all pg_class > entries with that name immediately before the breaking statement. Turns out I > had another table of the same name and design in another schema. > > I even knew about that but because an earlier part of the process was moving > that data out of that extra table, which had inadvertently been created in the > wrong schema, and placing it into the correct place I had forgotten about it. > That despite the fact that I even looked at that portion of code this afternoon > and merely noted what it was doing, i.e. it's aim, completely missing the fact > that the drop table statement was commented out. > > I won't say panic over because it isn't for me but it's pretty clear that I'm > not kicking some corner case bug in postgresql. Thanks for everyone's > input. Spectacular response times as usual. > > > -- > Nigel J. Andrews > > > ---------------------------(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
В списке pgsql-general по дате отправления: