Also, modified time doesn't need to be the current time, if it starts as "null" and is set on the first update, and all subsequent updates, the pre-update modified time could be used to help key the history pk.
Jim On Tue, Sep 25, 2018 at 1:45 AM James Keener <j...@jimkeener.com> wrote: > v3 UUIDs are basically MD5 hashes (v5 is sha1?). So for the same input > you'll always get the same hash. > > I had assumed the modified time would be the same; if that's not, then I'm > not sure and my gut tells me this becomes A Really Hard Problem™. > > Jim > > On Tue, Sep 25, 2018 at 1:38 AM digimer <li...@alteeve.ca> wrote: > >> On 2018-09-25 1:33 a.m., James Keener wrote: >> > Do you need a single field for the pk or can you just make it the >> > (original_table_pk, modified_time)? Alternatively, you could generate >> > a uuid v3 from the (original_table_pk, modified_time) using something >> > like uuid_generate_v3(uuid_nil(), original_table_pk || ":" || >> > modified_time)? >> >> I need to preset the modified_time, I can't use now() or else the value >> would differ between databases. Also, unless I am missing something, >> uuid_generate_v3() would generate a different UUID per trigger of the >> procedure, so I'd end up with different history_uuids on each database >> that I ran the query against. >> >> If I am missing something (and entirely possible I am), please hit me >> with a clue stick. :) >> >> digimer >> >>
