Re: a request for some experienced input..... - Mailing list pgsql-general

From Beth K. Gatewood
Subject Re: a request for some experienced input.....
Date
Msg-id 3A11ACA1.E5D847DD@mbt.washington.edu
Whole thread Raw
In response to Re: a request for some experienced input.....  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Responses Re: a request for some experienced input.....  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List 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



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: HUGE pg_sorttemp files, can I delete?
Next
From: Stephan Szabo
Date:
Subject: Re: a request for some experienced input.....