Re: [HACKERS] Beta for 4:30AST ... ?

>Don Baccus wrote:
>> 
>> At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
>> 
>> >   * -Add referential integrity(Jan)[primary]
>> 
>> This is only PARTIALLY complete:
>> 
>> MATCH FULL and MATCH <unspecified> foreign keys and their related
>> referential actions are complete.  MATCH PARTIAL isn't in - I'll be
>> doing that for 7.1.
>
>Can anyone point me to a written description of the expected
>functionality (and maybe limitations) provided by this release of RI? 
>I'm not asking for a definition of RI, but rather the status of
>*current* (7.0) pgsql RI functionality, i.e., what one should
>expect...

Well, I have some documentation patches currently out for the people
in the FK project, but we haven't gotten that completely finished,
and there are a few subtle differences right now due to some stuff
that we weren't able to get finished, in the meantime, while we're
working on that, I believe the following should sum it up:

* You can make both column and table constraints for foreign key constraints.  Currently, column FK constraints may not
specify NOT DEFERRABLE or INITIALLY (DEFERRED|IMMEDIATE) due to shift/reduce problems in the parser.
 

* You can only specify MATCH FULL or use MATCH unspecified for  the matching types.  MATCH PARTIAL should be in 7.1.

* If you do not specify the referenced columns, it will look for the primary key on the referenced table, but if you
specifyreferenced columns, it will not guarantee that those columns actually are a foreign key or have a unique
constraintupon  them.
 

* It does not enforce uniqueness of constraint names.  (A big reason that I didn't also due an FK version of ALTER
TABLEDROP CONSTRAINT)  Theoretically the constraint names for unique, check and fk constraints must all be checked to
guaranteeuniqueness.  Also, constraint names made by the system must also not conflict with existing constraint names,
andprobably should not fail, but instead have a way of forcing a unique name.
 

* ALTER TABLE ADD CONSTRAINT will allow the adding of any foreign key constraint that would be legal in the  table
constraintcontext (hopefully).  It also checks the current table data and refuses to add the constraint if the
constraintwould be immediately violated (again hopefully -- it's worked for our tests, but let's see what happens in
thereal world).
 

* pg_dump will dump CREATE CONSTRAINT TRIGGER statements for tables with foreign key constraints.  In data only dumps,
pg_dumpdoes a little bit of magic with the system catalogs to turn off all triggers on user defined tables and turn
themback on at the end.  It currently does not enforce that the data in between does not violate the constraint. This
isunfortunate, but we didn't come up with a good way to do this for possibly circular fk constraints and still be able
todeal with the possibility that the user may have changed the constraints since the dump, since it's data-only.
 

[Anything you can think of to add to this Don?]

Stephan