Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > What'd be easy is this:
>
> > - We already have two entry points for INSERT/UPDATE on FK
> > table, but the one for UPDATE is fortunately unused.
>
> > - We change analyze.c to install the RI_FKey_check_upd
>
Jan Wieck <[EMAIL PROTECTED]> writes:
> What'd be easy is this:
> - We already have two entry points for INSERT/UPDATE on FK
> table, but the one for UPDATE is fortunately unused.
> - We change analyze.c to install the RI_FKey_check_upd
> trigger if the cons
Jan Wieck wrote:
> Just discussed it with Tom Lane while he'd been here in
> Norfolk and it's even more ugly. We couldn't even pull out
> the FK's column defaults at this time to check if we are
> about to delete the corresponding PK because they might call
> all
Max Khon wrote:
> hi, there!
>
> On Mon, 23 Apr 2001, Jan Wieck wrote:
>
> > I just got trapped by one of my own features in the
> > referential integrity area.
> >
> > The problem is, that the trigger run on the FK row at UPDATE
> > allways checks and locks the refer
hi, there!
On Mon, 23 Apr 2001, Jan Wieck wrote:
> I just got trapped by one of my own features in the
> referential integrity area.
>
> The problem is, that the trigger run on the FK row at UPDATE
> allways checks and locks the referenced PK, even if the FK
>
