Skip site navigation (1) Skip section navigation (2)

Re: pg_depend patch

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pg_depend patch
Date: 2002-05-11 14:40:14
Message-ID: 022201c1f8f9$c38764e0$0f02000a@jester (view raw or flat)
Thread:
Lists: pgsql-patches
Almost forgot...

Heres changes for queries in pg_dump and psql to use pg_constraint
rather than pg_relcheck.


--
Rod
----- Original Message -----
From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: <pgsql-patches(at)postgresql(dot)org>
Sent: Friday, May 10, 2002 10:13 PM
Subject: Re: [PATCHES] pg_depend patch


> 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(at)zort(dot)ca>
> To: <pgsql-patches(at)postgresql(dot)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(at)postgresql(dot)org so that your
> > message can get through to the mailing list cleanly
> >
>


----------------------------------------------------------------------
----------


>
> ---------------------------(end of
broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

Attachment: psql_describe.c.patch
Description: application/octet-stream (907 bytes)
Attachment: pg_dump.patch
Description: application/octet-stream (3.1 KB)

In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2002-05-11 14:57:53
Subject: Re: troubleshooting pointers
Previous:From: Joe ConwayDate: 2002-05-11 04:04:32
Subject: Re: troubleshooting pointers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group