Re: altering foreign key without a table scan
От | Vincent de Phily |
---|---|
Тема | Re: altering foreign key without a table scan |
Дата | |
Msg-id | 22270524.vDhmFqSqtK@moltowork обсуждение исходный текст |
Ответ на | Re: altering foreign key without a table scan (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: altering foreign key without a table scan
|
Список | pgsql-general |
On Friday 19 August 2011 11:52:50 Tom Lane wrote: > Vincent de Phily <vincent.dephily@mobile-devices.fr> writes: > > Thanks for your answer. Experimenting a bit, those columns seem to have > > only a cosmetic impact, meaning that "\d" will show the schema you > > expect, but the behaviour remains unchanged (even after restarting > > postgres). > > > Digging further however, I found that pg_triggers can be used for my means > > : > 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 ? Thanks. -- Vincent de Phily
В списке pgsql-general по дате отправления: