| From: | postgresql(at)get-experience(dot)com |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: spi/timetravel: unique constraint violation on UPDATE |
| Date: | 2017-07-15 21:36:27 |
| Message-ID: | 0422ed19-76f7-210e-cc77-fd9b8018a8dd@get-experience.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Den 15. juli 2017 23:15, skrev Tom Lane:
> postgresql(at)get-experience(dot)com writes:
>> I'm having a problem with the timetravel extension. Following simple schema:
>> ...
>> What am I doing wrong here? According to the function comment in
>> timetravel.c it should:
>> a) set last-version row to NEW data; valid_from=now()
>> b) insert a new row with OLD data; valid_to=now() - at this point the
>> old valid_from is already supposed to be updated.
>
> I don't see anywhere in that comment that says "the old valid_from is
> already supposed to be updated". Given that the INSERT of the cloned row
> happens during the BEFORE UPDATE trigger, it would take a lot of magic
> for things to happen that way ;-).
Yeah, good point.
> Perhaps you could make your PK be on (id, valid_from, valid_to).
Doesn't really work because valid_to would change on UPDATE. I'd need to
update foreign relations with another trigger which would be very ugly.
I guess the only solution is to write my own time travel trigger
function and do update before insert...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-07-15 22:03:13 | Re: spi/timetravel: unique constraint violation on UPDATE |
| Previous Message | Tom Lane | 2017-07-15 21:15:33 | Re: spi/timetravel: unique constraint violation on UPDATE |