From: | Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jerry Sievers <gsievers19(at)comcast(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: altering foreign key without a table scan |
Date: | 2011-08-19 17:19:53 |
Message-ID: | 4833286.45n85cmKOJ@moltowork |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Friday 19 August 2011 12:55:01 Tom Lane wrote:
> Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr> writes:
> > On Friday 19 August 2011 11:52:50 Tom Lane wrote:
> >> IIRC, there are fields of pg_constraint that are copied into the
> >> pg_trigger rows for the supporting triggers, so as to save one catalog
> >> lookup at run time. If you diddle one manually, you'd better diddle
> >> both.
> >
> > Some relid values are indeed duplicated in pg_constraint and pg_trigger,
> > but it doesn't look like I need to fiddle with those ?
> >
> > I'm only touching pg_trigger.tgfoid and
> > pg_constraint.confdeltype/confupdtype (which indeed seem to say the
> > same thing in a different way). Do you know if there is something else
> > I've missed ?
>
> Yeah, that seems to be it except for the deferrable/deferred fields,
> which match up in the obvious way. I had been thinking the RI triggers
> avoided doing a lookup in pg_constraint, but that was mistaken. (I
> think we used to store all that info in tgargs, but we evidently don't
> anymore.)
Thanks, I'll look into applying those next week then. If I never get back to
the list about it, it'll mean that it worked without issues :)
--
Vincent de Phily
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Morgan Lloyd | 2011-08-19 17:45:22 | Listen/notify and ODBC |
Previous Message | Tom Lane | 2011-08-19 16:55:01 | Re: altering foreign key without a table scan |