Re: 1 foreign key to 2 different tables?
От | Timothy Perrigo |
---|---|
Тема | Re: 1 foreign key to 2 different tables? |
Дата | |
Msg-id | 96E47D1C-9CF7-11D8-9AEE-000A95C4F0A2@wernervas.com обсуждение исходный текст |
Ответ на | Re: 1 foreign key to 2 different tables? ("Ryan Riehle" <rkr@buildways.com>) |
Список | pgsql-general |
I don't know if this will work in your situation, but you might look into having table A and table B inherit from a common base table (where the column referenced by the foreign key in C is defined). Tim On May 2, 2004, at 2:51 AM, Ryan Riehle wrote: > Thanks for your input. Yes, there is a lot more to this part of the > schema. > The current stucture makes the most sense to us so far, after lots of > thinking. If you are interested I can offer you more details about the > structure, but for now I am looking for how to implement this type of > constraint with a trigger or another method - if there is a better way. > > -Ryan Riehle > http://www.buildways.com > > > > -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Bruno Wolff > III > Sent: Saturday, May 01, 2004 9:40 PM > To: Ryan Riehle > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] 1 foreign key to 2 different tables? > > > On Sat, May 01, 2004 at 18:09:34 -0400, > Ryan Riehle <rkr@buildways.com> wrote: >> For what I am reading now it looks like this is an opportunity to use >> CREATE ASSERTION, but this functionality appears to be unstable so >> far and > is not >> recommended for production environments. Is this correct? >> Otherwise, > can >> someone post an example of implementing a check constraint or trigger >> since I have not created a check onstraint that is above common >> complexity and and have never tried a trigger. > > The simplest way to do this is probably be to use two separate fields > to > make the references and make sure exactly one of them is nonnull. You > also > might want to rethink your design. That you want to do this suggests > that > there is something odd about the schema design you have come up with. > > ---------------------------(end of > broadcast)--------------------------- > TIP 8: explain analyze is your friend > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 8: explain analyze is your friend >
В списке pgsql-general по дате отправления: