Re: a request for some experienced input.....

From: "Beth K(dot) Gatewood" <bethg(at)mbt(dot)washington(dot)edu>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: a request for some experienced input.....
Date: 2000-11-14 21:20:33
Message-ID: 3A11ACA1.E5D847DD@mbt.washington.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>

Stephan-

Thank you so much for taking the effort to answer this these questions. You
help is truly appreciated....

I just have a few points for clarification.

>
> MATCH PARTIAL is a specific match type which describes which rows are
> considered matching rows for purposes of meeting or failing the
> constraint. (In match partial, a fktable (NULL, 2) would match a pk
> table (1,2) as well as a pk table (2,2). It's different from match
> full in which case (NULL,2) would be invalid or match unspecified
> in which case it would match due to the existance of the NULL in any
> case). There are some bizarre implementation details involved with
> it and it's different from the others in ways that make it difficult.
> It's in my list of things to do, but I haven't come up with an acceptable
> mechanism in my head yet.

Does this mean, currently that I can not have foreign keys with null values?

>
>
> PENDANT adds that for each row of the referenced table the values of
> the specified column(s) are the same as the values of the specified
> column(s) in some row of the referencing tables.

I am not sure I know what you mean here.....Are you saying that the value for
the FK column must match the value for the PK column?

>
>
> If all you need is match full or the default unspecified match and you
> don't need pendant, then this part doesn't really concern you.
>
> > Frankly, I am concerned when I read that there may be 'issues' with
> > referential integrity especially since some of our data will be fleeting
> > (i.e. there will be no files outside of the database from which we could
> > re-capture the data). I am especially paranoid about losing this type
> > of data (as anyone would be!)
>
> The main issues in 7.0 are that older versions (might be fixed in
> 7.0.3) would fail very badly if you used alter table to rename tables that
> were referenced in a fk constraint and that you need to give update
> permission to the referenced table. For the former, 7.1 will (and 7.0.3
> may) give an elog(ERROR) to you rather than crashing the backend and the
> latter should be fixed for 7.1 (although you still need to have write
> perms to the referencing table for referential actions to work properly)

Are the steps to this outlined somewhere then?

Thanks alot!

Beth

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kevin English 2000-11-14 21:42:32 Transaction Abort during insert using libpq
Previous Message Tom Lane 2000-11-14 21:13:45 Re: HUGE pg_sorttemp files, can I delete?