On 08/01/2019 23:26, Corey Huinker wrote:
> On Fri, Jan 4, 2019 at 7:49 AM Peter Eisentraut
> wrote:
>>
>> On 25/12/2018 00:56, Corey Huinker wrote:
>>> The regression diff (attached) seems to imply that the triggers simply
>>> are not firing, though.
>>
>> The reason for this was explained by Dea
On Fri, Jan 4, 2019 at 7:49 AM Peter Eisentraut
wrote:
>
> On 25/12/2018 00:56, Corey Huinker wrote:
> > The regression diff (attached) seems to imply that the triggers simply
> > are not firing, though.
>
> The reason for this was explained by Dean. If you take out the check
> that he mentioned,
On 25/12/2018 00:56, Corey Huinker wrote:
> The regression diff (attached) seems to imply that the triggers simply
> are not firing, though.
The reason for this was explained by Dean. If you take out the check
that he mentioned, then your trigger fires but crashes. In your changed
unique_key_rec
On Tue, 25 Dec 2018 at 08:04, Dean Rasheed wrote:
> Take a look at this code in AfterTriggerSaveEvent():
>
Note that the intention behind that code is that in the (fairly
common) case where an insert or update operation is known to not lead
to any potential PK/UNIQUE index violations, the overhea
On Mon, 24 Dec 2018 at 23:57, Corey Huinker wrote:
>
> So I took a first pass at this, and I got stuck.
>
> [snip]
>
> Any idea where I went wrong?
Take a look at this code in AfterTriggerSaveEvent():
/*
* If the trigger is a deferred unique constraint check trigger, only
So I took a first pass at this, and I got stuck.
The basic design is that instead of creating one row-level trigger per
deferrable unique constraint, we instead create one insert-statement level
trigger and one update-statement level trigger. Both call the function
unique_key_recheck(), which now
