On Friday 19 August 2011 12:55:01 Tom Lane wrote:
> Vincent de Phily 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 ti
Vincent de Phily 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
On Friday 19 August 2011 11:52:50 Tom Lane wrote:
> Vincent de Phily 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
> >
Vincent de Phily writes:
> On Thursday 18 August 2011 13:08:18 Jerry Sievers wrote:
>> Your 2 catalog fields of interest are;
>> pg_constraint.(confupdtype|confdeltype)
>>
>> Changing those for the relevant FKs should satisfy your needs. I am
>> not aware of those field values being duplicated a
On Thursday 18 August 2011 13:08:18 Jerry Sievers wrote:
> Vincent de Phily writes:
> > The thing is, I know there is no violation by existing data, because of
> > the existing fkey. So locking and scaning the table to add the
> > "duplicate" fkey is>
> > not necessary. In a sense, I'm looking fo
Vincent de Phily writes:
> Hi list,
>
> as part of a db schema update, I'd like to alter the "on update" property of
> a
> fkey, for example going from :
>> ALTER TABLE ONLY foo ADD CONSTRAINT foo_barid_fkey FOREIGN KEY (barid)
>> REFERENCES bar(id) ON UPDATE CASCADE ON DELETE CASCADE;
> to :
>
