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
>