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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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