Re: Incomprehensible behaviour of a foreign key.

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(dot)org(at)localhost(dot)postgresql(dot)org
> Date: Sun, 20 Jul 2003 21:23:12 +0100 (BST)
> From: "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
> X-Sender: nandrews(at)ponder(dot)fairway2k(dot)co(dot)uk
> To: pgsql-general(at)postgresql(dot)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