Oooooh, this is a very interesting approach! I didn't realize any UUIDs could be created in a predictable way. Thank you, this might be what I need.
digimer
On 2018-09-25 1:47 a.m., James Keener wrote:
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
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 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
