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
On Tue, Sep 25, 2018 at 1:45 AM James Keener <j...@jimkeener.com
<mailto: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
<mailto: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
