On Tue, Sep 25, 2018, 2:19 AM digimer wrote:
> Oh, 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.
>
Yep, DCE defined about 5 different versions of UUIDs, each with somewhat
differing characteristic
On 2018-09-25 6:41 p.m., digimer wrote:
On 2018-09-25 6:22 p.m., Tim Cross wrote:
digimer writes:
Hi all,
I've got an interesting use case that I am stuck on. It's a bit of a
complicated environment, but I'll try to keep it simple.
In short; I have a history schema that has tables t
On 2018-09-25 6:22 p.m., Tim Cross wrote:
digimer writes:
Hi all,
I've got an interesting use case that I am stuck on. It's a bit of a
complicated environment, but I'll try to keep it simple.
In short; I have a history schema that has tables that match the
public schema, plus one 'hist
digimer writes:
> Hi all,
>
> I've got an interesting use case that I am stuck on. It's a bit of a
> complicated environment, but I'll try to keep it simple.
>
> In short; I have a history schema that has tables that match the
> public schema, plus one 'history_id' column that has a simpl
Oh, 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 o
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 wrote:
> v3 UUIDs are basically MD5
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 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_t
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)?
On 2018-09-25 1:22 a.m., digimer wrote:
Can I tell a produce to use a specific UUID?
s/produce/procedure/
Hi all,
I've got an interesting use case that I am stuck on. It's a bit of a
complicated environment, but I'll try to keep it simple.
In short; I have a history schema that has tables that match the
public schema, plus one 'history_id' column that has a simple sequential
bigserial value.
11 matches
Mail list logo
