On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
>>> Would you feel comfortable with a patch which threw an error on
>>> the DELETE case, as it does on the UPDATE case?
>>
>> Yes, though with a little additional twist. The twist being that
>> I'd like the error to be thrown earlier, at the time of the
>> offending UPDATE or DELETE, not later, when the original UPDATE or
>> DELETE which caused the BEFORE trigger invocation stumbles over
>> the updated row. It not only seems more logical that way, but it
>> also makes it possible for the trigger to catch the error, and
>> react accordingly.
>
> I hadn't thought of that. It does seem better in every way except
> for how much work it takes to do it and how much testing it needs to
> have confidence in it. Definitely not 9.1 material.
IMHO, none of this is 9.1 material. It's been like this forever, and
it sucks, but it doesn't suck particularly more than any of the other
things that we didn't get around to fixing in 9.1. In fact, I'd go so
far as to argue that this would be just about the worst imaginable
type of patch to slip into a release at the last minute. On the one
hand, I think there's a real chance of breaking things in subtle ways
that are difficult to detect; and on the other hand, a significant
percentage of users will get no benefit from any change we make here,
just because this is something that most people don't do. People who
would otherwise be tempted to write their applications this way will
end up not doing so precisely because it currently does not work. So
I think we should focus on getting the right semantics here, rather
than trying to minimize the scope of the change.
I'm not sure I understand the justification for throwing an error.
Updating a row twice is not an error under any other circumstances;
nor is deleting a row you've updated. Why should it be here?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
