Re: a request for some experienced input.....
От | Beth K. Gatewood |
---|---|
Тема | Re: a request for some experienced input..... |
Дата | |
Msg-id | 3A11ACA1.E5D847DD@mbt.washington.edu обсуждение исходный текст |
Ответ на | Re: a request for some experienced input..... (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: a request for some experienced input.....
|
Список | 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 по дате отправления: