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

pg_constraint

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_constraint
Date: 2002-04-26 02:30:45
Message-ID: 047d01c1ecca$5efe0820$ad02000a@jester (view raw or flat)
Thread:
Lists: pgsql-hackers
For tracking of Foreign Keys, Check constraints, and maybe NULL / NOT
NULL (specific type of check constraint) I intend to create (as per
suggestion) pg_constraint.

conrelid
conname
contype ('c'heck, 'f'oreign key, ???)
conkey (int2vector of columns of relid, like pg_index.indkey)
connum int4 -- unique identifying constraint number for the relation
id.
consrc
conbin

Dependencies would be on conrelid, and connum in pg_depend.  If each
constraint has a unique number for the relation OIDs aren't required
here.  Much like pg_attribute.

pg_class.relchecks would change to mean relconstraints, though I wont
change the column name.

A view to pg_relcheck would be created.

End result? Foreign Keys will be tracked and restricted / cascaded
through via pg_depend code (see patches archive in April).  This would
knock several items off the TODO list.

I'm not exactly sure how to find out what columns a check constraint
depends on, but I'm sure I'll figure that out sooner or later.

Any thoughts or suggestions?  Is there any reason to allow a check in
a namespace other than the relation it's tied to?  Spec seems to allow
that, but is it actually useful?
--
Rod


Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-26 02:32:14
Subject: Re: What is wrong with hashed index usage?
Previous:From: Curt SampsonDate: 2002-04-26 02:27:17
Subject: Re: Sequential Scan Read-Ahead

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