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
>
Hi,
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
attributes didn't change. That's because if there'd be an
