Ok. Fixed constraint names. Found and fixed an issue with index table
locks. It now piggy backs DeleteComment() on dependDelete() since 90%
of the cases had both calls.
Thanks,
Rod
----- Original Message -----
From: "Rod Taylor" <rbt@zort.ca>
To: <pgsql-patches@postgresql.org>
Sent: Wednesday, May 08, 2002 10:07 PM
Subject: [PATCHES] pg_depend patch
> Creation of:
> src/backend/catalog/pg_constraint.c
> src/backend/catalog/pg_depend.c
> src/include/catalog/pg_constraint.h
> src/include/catalog/pg_depend.h
> src/test/regress/expected/drop.out
>
> Removed src/backend/catalog/pg_relcheck.h
>
>
> TODO list attached which has a list of what I've done. Additional
notes
> are below.
>
>
> Postgresql TODOs completed with this patch:
>
> - Add pg_depend table for dependency recording (slightly different
> structure)
> - Auto-destroy sequence on DROP of table with SERIAL
> - Prevent column (relation) dropping if column is used by foreign
key
> - Make foreign keys easier to identify.
>
> Worth mentioning:
> - Prevent dropping system required functions and types.
> - Move all constraints under a single namespace (unique to the
relation)
>
>
> pg_dump can be easily modified to pick up the new foreign key
> structure. There is NOT a mechanism to convert trigger style
foreign
> keys into constraint entries.
>
> Renaming SERIAL sequences to include the OID would be useful and
simple.
>
> Function contents, view contents, and default values can depend on
> objects. Currently not tracked. One needs to parse their node tree
for
> all types, functions, relations, columns, and other references
recording
> these in the pg_depend table. Patch is still quite useful for other
> reasons though :)
>
>
> Regression tests will fail due to the OIDs used to name constraints
> being different with each run. Suggested solution is to disable
NOTICE
> during regression tests. See 'Regression tests and NOTICE
statements'
> on hackers.
>
> ALTER TABLE DROP CONSTRAINT is still not completely functional (same
> state as before).
>
> Documentation updates will follow. They'll consist primarily of
> describing RESTRICT and CASCADE keywords.
>
>
> NOTE: REINDEX may do strange things. It appears to be functional,
but
> has a special hook through dependencies so it won't complain too
loudly.
> Basically ignores restrictions and doesn't cascade beyond implicit
> drops.
>
>
> Enjoy!
>
> --
> Rod
>
----------------------------------------------------------------------
----------
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
