Re: UPDATE SET (a,b,c) = (SELECT ...) versus rules
От | Andres Freund |
---|---|
Тема | Re: UPDATE SET (a,b,c) = (SELECT ...) versus rules |
Дата | |
Msg-id | 20140614195230.GF6763@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: UPDATE SET (a,b,c) = (SELECT ...) versus rules (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: UPDATE SET (a,b,c) = (SELECT ...) versus rules
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: