Re: Weird procedure question

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 <jim(at)jimkeener(dot)com
> <mailto:jim(at)jimkeener(dot)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 <lists(at)alteeve(dot)ca
> <mailto:lists(at)alteeve(dot)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
>