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