Philip Warner <pjw@rhyme.com.au> writes:
>> Is there some obvious (to anyone who knows something about pg internals)
>> reason why this is *not* a good idea?
> Putting this another way, does anyone object to this being implemented, *at
> least* in the case of single row updates?
Provide a specification *first*. What exactly do you expect to do,
and how will the code behave in the case of multiple affected rows,
zero affected rows, same row affected multiple times (possible with
a joined UPDATE), inherited UPDATE that affects rows in multiple tables,
inserts/updates that are suppressed or redirected or turned into
multiple operations (possibly on multiple tables) by rules or triggers,
etc etc? Not to mention the juicy topics of access permissions and
possible errors. Also, how will this affect the frontend/backend
protocol and what are the risks of breaking existing frontend code?
Finally, how does your spec compare to similar features in other DBMSs?
I don't have any fundamental objection to it given a well-thought-out
specification and implementation ... but I don't want to find us stuck
with supporting a half-baked nonstandard feature. We have quite enough
of those already ;-)
regards, tom lane
