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

Re: pg_constraint

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_constraint
Date: 2002-04-26 14:58:53
Message-ID: 1c6201c1ed32$e1d86ed0$ad02000a@jester (view raw or flat)
Thread:
Lists: pgsql-hackers
> Could we instead insist on a unique name per-table, and make this
table's
> key be (conrelid, conname)?  Assigning a number seems quite
artificial.

The only problem with this is that I don't want the rename of a
constraint to have to fall over into the pg_depend table.  pg_depend
is currently happy with system OIDS or a Relation OID and some unique
number to represent it -- much as pg_description wouldn't want to know
the name of the constraint for the ability to add a comment to it.

> consrc/conbin seem to only cover the check-constraint case.  Need
some
> thought about what to store for foreign keys (ideally, enough info
for
> pg_dump to reconstruct the REFERENCES spec without looking at the
> triggers) and unique/primary keys (a link to the implementing index
> seems like a good idea here).

I will implement the various flags required for these.  conupdtyp,
condeltyp (on update type and on delete type respectively) as well as
immediate and deferrable bools.

> > 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.
>
> pull_var_clause() on the nodetree representation is your friend.

Thanks for the tip.

> I see a difficulty in the above representation though: what if a
check
> constraint refers to > INDEX_MAX_KEY columns?  Maybe conkey had
better
> be an int2[] variable-length array.

Good point.


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-26 15:10:18
Subject: Re: PSQL \x \l command issues
Previous:From: Tom LaneDate: 2002-04-26 14:50:32
Subject: Re: pg_constraint

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