Alvaro Herrera wrote:
> Kevin Grittner escribió:
>> Tom Lane wrote:
>
>>> Also, it doesn't appear that we ever got around to preparing
>>> documentation updates, but I think we definitely need some if
>>> we're going to start throwing errors for things that used to be
>>> allowed. Since Kevin has
Alvaro Herrera wrote:
> Kevin Grittner escribió:
>> Tom Lane wrote:
>
>>> Also, it doesn't appear that we ever got around to preparing
>>> documentation updates, but I think we definitely need some if
>>> we're going to start throwing errors for things that used to be
>>> allowed. Since Kevin has
Kevin Grittner escribió:
> Tom Lane wrote:
> > Also, it doesn't appear that we ever got around to preparing
> > documentation updates, but I think we definitely need some if
> > we're going to start throwing errors for things that used to be
> > allowed. Since Kevin has the most field experience
Tom Lane wrote:
> "Kevin Grittner" writes:
>> At any rate, I think we might want to apply Tom's patch for this
>> while 9.3 is still early in development, to see what else might
>> shake out from it while there is still plenty of time to fix any
>> issues. It's now looking good from my perspecti
"Kevin Grittner" writes:
> At any rate, I think we might want to apply Tom's patch for this
> while 9.3 is still early in development, to see what else might
> shake out from it while there is still plenty of time to fix any
> issues. It's now looking good from my perspective.
I just re-read the
"Kevin Grittner" wrote:
> We discussed it to the point of consensus, and Tom wrote a patch
> to implement that. Testing in my shop hit problems for which the
> cause was not obvious. I don't know whether there is a flaw in
> the designed approach that we all missed, a simple programming bug
>
On Wed, Aug 8, 2012 at 09:26:41AM -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > Did we ever decide on this?
>
> We discussed it to the point of consensus, and Tom wrote a patch to
> implement that. Testing in my shop hit problems for which the cause
> was not obvious. I don't kn
Bruce Momjian wrote:
> Did we ever decide on this?
We discussed it to the point of consensus, and Tom wrote a patch to
implement that. Testing in my shop hit problems for which the cause
was not obvious. I don't know whether there is a flaw in the
designed approach that we all missed, a simp
Did we ever decide on this? Is it a TODO?
---
On Fri, Jul 22, 2011 at 04:01:20PM -0500, Kevin Grittner wrote:
> Robert Haas wrote:
> > On Wed, Jul 20, 2011 at 2:58 PM, Kevin Grittner
> > wrote:
> >> So basically, the goal
Florian Pflug wrote:
> Another option would be to re-issue the DELETE from the BEFORE
> DELETE trigger, and then return NULL. It'll cause the BEFORE
> DELETE trigger to be invoked recursively, but presumably the
> second invocation could easily detect that all required pre-delete
> actions have
On Aug9, 2011, at 15:41 , Kevin Grittner wrote:
> Florian Pflug wrote:
>
>> To summarize, here's what I currently believe would be a sensible
>> approach:
>>
>> After every BEFORE trigger invocation, if the trigger returned
>> non-NULL, check if latest row version is still the same as when
>>
Florian Pflug wrote:
> To summarize, here's what I currently believe would be a sensible
> approach:
>
> After every BEFORE trigger invocation, if the trigger returned
> non-NULL, check if latest row version is still the same as when
> the trigger started. If not, complain.
That certain
Florian Pflug wrote:
> I think it would be helpful if we had a more precise idea about
> the intended use-cases. So far, the only use-case that has been
> described in detail is the one which made Kevin aware of the
> problem. But if I understood Kevin correctly, that fact that they
> use BEFORE
On Aug8, 2011, at 17:35 , Florian Pflug wrote:
> I think it would be helpful if we had a more precise idea about the
> intended use-cases. So far, the only use-case that has been described in
> detail is the one which made Kevin aware of the problem. But if I
> understood Kevin correctly, that fact
On Aug8, 2011, at 17:02 , Kevin Grittner wrote:
> So, we have three options on the table here:
>
> (1) We (the Wisconsin Courts) are using a very simple fix to work
> around the issue so we can move forward with conversion to
> PostgreSQL triggers. A DELETE is allowed to complete if the BEFORE
>
Robert Haas wrote:
> Florian Pflug wrote:
>> Going down that road opens the door to a *lot* of subtle semantic
>> differences between currently equivalent queries. For example,
>>
>> UPDATE T SET f=f, a=1
>>
>> would behave differently then
>>
>> UPDATE T SET a=1
>>
>> because in the first case
On Wed, Aug 3, 2011 at 12:27 PM, Florian Pflug wrote:
> Going down that road opens the door to a *lot* of subtle semantic
> differences between currently equivalent queries. For example,
>
> UPDATE T SET f=f, a=1
>
> would behave differently then
>
> UPDATE T SET a=1
>
> because in the first cas
Florian Pflug wrote:
> To me, it still seems conceptionally cleaner to just decree that a
> row must not be modified while BEFORE triggers are running,
> period.
>
> This, BTW, also matches what Oracle does, only on a per-row
> instead of per-table basis. Oracle AFAIR simply forbids touching
>
Robert Haas wrote:
> Florian Pflug wrote:
>> Here's a step-by-step description of what happens in the case of
>> two UPDATES, assuming that we don't ignore any updated and throw
>> no error.
>>
>> 1) UPDATE T SET ... WHERE ID=1
>> 2) Row with ID=1 is found & locked
>> 3) BEFORE UPDATE triggers
On Aug3, 2011, at 17:57 , Robert Haas wrote:
> On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug wrote:
>> The different between Kevin's original patch and my suggestion is, BTW,
>> that he made step (7) through an error while I suggested the error to
>> be thrown already at (4).
>
> I think Kevin's
On Aug3, 2011, at 17:55 , Robert Haas wrote:
> On that note, I think in some ways the problems we're hitting here are
> very much like serialization anomalies.
Yeah, I had the same feeling of familiarity ;-)
> If the user updates a tuple
> based on its PK and sets some non-PK field to a constant,
On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug wrote:
> On Aug3, 2011, at 04:54 , Robert Haas wrote:
>> On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
>> wrote:
> Would you feel comfortable with a patch which threw an error on
> the DELETE case, as it does on the UPDATE case?
Yes
On Wed, Aug 3, 2011 at 10:48 AM, Kevin Grittner
wrote:
> As have many other data mangling bugs which we fix in minor
> releases. Our point here is that it's never been like this in any
> product that the Wisconsin Courts has used for triggers, and never
> will be.
I don't believe this is very si
Robert Haas wrote:
> Kevin Grittner 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
On Aug3, 2011, at 04:54 , Robert Haas wrote:
> On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
> 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
On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
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 ti
"Kevin Grittner" wrote:
> Florian Pflug wrote:
>> Hm, OK I see your point now I believe. This is not so much about
>> wanting to put things into BEFORe triggers which doesn't really
>> fit there, but instead avoiding weeks of debugging if someones
>> messes up.
>
> I would say that is the ove
Florian Pflug wrote:
> On Aug2, 2011, at 17:03 , Kevin Grittner wrote:
> Hm, OK I see your point now I believe. This is not so much about
> wanting to put things into BEFORe triggers which doesn't really
> fit there, but instead avoiding weeks of debugging if someones
> messes up.
I would say
On Aug2, 2011, at 17:03 , Kevin Grittner wrote:
> Florian Pflug wrote:
>> First, I'm not sure this is even a bug. To me, it seems that
>> postgres currently resolves an inherently ambiguous situation in
>> one possible way, while you expect it to pick another. It might be
>> that the behaviour tha
Florian Pflug wrote:
> On Aug1, 2011, at 20:02 , Kevin Grittner wrote:
>> I consider the trigger behavior addressed by this patch to be a
>> bug, and serious enough to merit inclusion of a fix in the 9.1
>> release, even at this late stage.
>
> I'm sorry but I disagree, on multiple grounds.
T
On Aug1, 2011, at 20:02 , Kevin Grittner wrote:
> "Kevin Grittner" wrote:
> I consider the trigger behavior addressed by this patch to be a bug,
> and serious enough to merit inclusion of a fix in the 9.1 release,
> even at this late stage.
I'm sorry but I disagree, on multiple grounds.
First, I
"Kevin Grittner" wrote:
> By the way, my current patch does break two existing UPDATE
> statements in the regression test misc.sql file:
Fixed in the attached version of the patch.
I consider the trigger behavior addressed by this patch to be a bug,
and serious enough to merit inclusion of a
Robert Haas wrote:
> On Mon, Jul 25, 2011 at 12:26 PM, Kevin Grittner
> wrote:
>> There's no doubt that it would be better the way you're
>> suggesting; but it looks to me like about five times as many
>> lines of code, harder to be sure it's right, and probably forcing
>> me to learn a few new s
On Mon, Jul 25, 2011 at 12:26 PM, Kevin Grittner
wrote:
> There's no doubt that it would be better the way you're suggesting;
> but it looks to me like about five times as many lines of code,
> harder to be sure it's right, and probably forcing me to learn a few
> new subsystems of PostgreSQL inte
Robert Haas wrote:
> Well, it seems to me that if the trigger update and the main
> update were executed as separate commands (with no triggers
> involved) it would often be the case that they'd dovetail nicely.
> When this has come up for me, it's usually been the case that the
> sets of field
On Fri, Jul 22, 2011 at 5:01 PM, Kevin Grittner
wrote:
>> Your scenario is a BEFORE DELETE trigger that does an UPDATE on
>> the same row, but I think this problem also occurs if you have a
>> BEFORE UPDATE trigger that does an UPDATE on the same row. I
>> believe the second update gets silently
"Kevin Grittner" wrote:
> I believe that we can get DELETE behavior which is every bit as
> sensible as INSERT behavior with a very small change.
> I think the right thing is to throw an error if the old row for a
> BEFORE UPDATE is updated by the same transaction and the trigger
> function ul
Robert Haas wrote:
> On Wed, Jul 20, 2011 at 2:58 PM, Kevin Grittner
> wrote:
>> So basically, the goal of this patch is to ensure that a BEFORE
>> DELETE trigger doesn't silently fail to delete a row because that
>> row was updated during the BEFORE DELETE trigger firing (in our
>> case by secon
Robert Haas wrote:
> I think this problem also occurs if you have a BEFORE
> UPDATE trigger that does an UPDATE on the same row.
I'm pretty sure you're right, and I do intend to cover that in the
final patch.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Wed, Jul 20, 2011 at 2:58 PM, Kevin Grittner
wrote:
> So basically, the goal of this patch is to ensure that a BEFORE
> DELETE trigger doesn't silently fail to delete a row because that
> row was updated during the BEFORE DELETE trigger firing (in our case
> by secondary trigger firing).
I've
We're nearing completion of testing the migration of a lot of code
which used our custom Java framework into PostgreSQL functions and
triggers. Yesterday our testers ran into surprising behavior
related to delete triggers. A test case is presented on the -bugs
list, but basically it amounts to th
41 matches
Mail list logo
