On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > Hi,
> > On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
> >> Given that ON UPDATE rules are close to being a deprecated feature,
> >> it doesn't seem appropriate to work harder than this; and frankly
> >> I don't see how we could avoid multiple sub-select evaluations anyway,
> >> if the NEW references are in WHERE or other odd places.
> >>
> >> Another possible answer is to just throw a "not implemented" error;
> >> but that doesn't seem terribly helpful, and I think it wouldn't save
> >> a lot of code anyway.
>
> > I vote for throwing an error. This would make the rules about how rules
> > can be used safely even more confusing. I don't think anybody would be
> > helped by that. If somebody wrote a halfway sane ON UPDATE rule
> > (i.e. calling a function to do the dirty work) it wouldn't be sane
> > anymore if somebody starts to use the new syntax...
>
> Well, it wouldn't be "unsafe" (barring volatile functions in the UPDATE,
> which are unsafe already). It might be slow, but that's probably better
> than failing.
I forgot the details, but IIRC it's possible to write a ON UPDATE ...
DO INSTEAD rule that's safe wrt multiple evaluations today by calling a
function passing in the old pkey and NEW. At least I believed so at some
point in the past :P
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
