Re: UUID v7

On Wed, Dec 4, 2024 at 9:04 AM Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
>
>
> > On 2 Dec 2024, at 11:00, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > The monotonicity of generated UUIDv7 is guaranteed only within a
> > single backend.
>
> I've addressed all items, except formatting a table... I can't build docs to make a reasonable judgement if the table looks OK.
>

Thank you for updating the patch!

> Changes:
> - restored leakproof flag of functions without arguments to be consistent with gen_random_uuid()

If I understand the below Peter's comment correctly, we don't need to
mark all of three functions leakproof:

>
> * src/test/regress/expected/opr_sanity.out
>
> +uuidv4()
> +uuidv7()
> +uuidv7(interval)
>
> Functions without arguments don't need to be marked leakproof.
>
> uuidv7(interval) internally calls timestamptz_pl_interval(), which is
> not leakproof, so I don't think that classification is sound.

I've attached the updated patches. The 0001 patch unmarks the existing
gen_random_uuid() leakproof and is being discussed on another
thread[1]. I'm going to push the main UUIDv7 patch barring objections
and further comments, after pushing the fix for gen_random_uuid().

>
> Also PFA a prototype of making uuidv7() ordered across all backends via keeping previous_ns in shared memory. IMO it's overcomplicating and RFC does not require such guarantees. Also, this would cost us several hundreds of ns on each uuidv7() call. I think we should focus on committing existing implementation and leave such things for a future improvement.

I also feel like it's overcomplicating. We can focus on the main patch
and can implement it later if we really need it.

Regards,

[1] https://www.postgresql.org/message-id/CAD21AoBE1ePPWY1NQEgk3DkqjYzLPZwYTzCySHm0e%2B9a69PfZw%40mail.gmail.com

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com