From: | patrick keshishian <patrick+pgsql(at)pioneerdigital(dot)com> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: re: 7.1.2 and foreign key unique constraint. |
Date: | 2001-08-03 20:42:38 |
Message-ID: | 20010803134238.B1885@pioneerdigital.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Stephan,
Thanks for your reply and suggestions. I was hoping for a
solution that would not require me to break apart any of the
tables or employ new ones.
But apparently i have no choice.
One would think that there would a such a construct defined in
SQL for specifying a field in a table with restriction placed on
its values based on values in a 'foreign table field'.
I'm sure i wouldn't be the only person that would utilize such a
feature.
Thanks again,
On Thu, Aug 02, 2001 at 03:20:24PM -0700, Stephan Szabo wrote:
>
> > I ran accross this problem upon upgrading our database from 7.0.3
> > to 7.1.2:
> >
> > ERROR: UNIQUE constraint matching given keys for referenced
> > table "some_table" not found
>
> Yeah, we fixed this to follow spec (sql actually requires that the
> references be to a unique or primary key constraint)
>
> For references to news_stories, you probably need to break news_stories
> into two more normalized tables that actually have candidate keys.
> I'd guess one would be id and fields that depend only on id and the other
> would be id, media type and fields that depend on both of those.
>
> I'm not so sure for the other constraint (still trying to think that case
> through)
--
patrick keshishian
Gnu __ _
-o)/ / (_)__ __ ____ __
/\\ /__/ / _ \/ // /\ \/ /
_\_v __/_/_//_/\_,_/ /_/\_\
From | Date | Subject | |
---|---|---|---|
Next Message | Trond Eivind Glomsrød | 2001-08-03 20:44:41 | Re: HELP! BUG? pg_dump mucks up grant/revoke |
Previous Message | Tom Lane | 2001-08-03 20:35:39 | Re: HELP! BUG? pg_dump mucks up grant/revoke |