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 specify
  referenced columns, it will not guarantee that those columns
  actually are a foreign key or have a unique constraint upon 
  them.

* It does not enforce uniqueness of constraint names.  (A big
  reason that I didn't also due an FK version of ALTER TABLE
  DROP CONSTRAINT)  Theoretically the constraint names for
  unique, check and fk constraints must all be checked to
  guarantee uniqueness.  Also, constraint names made by the
  system must also not conflict with existing constraint
  names, and probably 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 constraint context (hopefully).  It also checks
  the current table data and refuses to add the constraint
  if the constraint would be immediately violated (again
  hopefully -- it's worked for our tests, but let's see
  what happens in the real world).

* pg_dump will dump CREATE CONSTRAINT TRIGGER statements for
  tables with foreign key constraints.  In data only dumps,
  pg_dump does a little bit of magic with the system catalogs
  to turn off all triggers on user defined tables and turn
  them back on at the end.  It currently does not enforce
  that the data in between does not violate the constraint.
  This is unfortunate, but we didn't come up with a good
  way to do this for possibly circular fk constraints and
  still be able to deal 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