On 2014-06-14 15:48:52 -0400, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers