Re: UUID v7 - Mailing list pgsql-hackers

From Nikolay Samokhvalov
Subject Re: UUID v7
Date
Msg-id CAM527d-REt6HZDZmynpZ1gF-gwCa31ntGq=xCmDbXaguvEbVbA@mail.gmail.com
Whole thread Raw
In response to Re: UUID v7  (Nikolay Samokhvalov <nik@postgres.ai>)
List pgsql-hackers

On Wed, Jan 24, 2024 at 8:40 PM Nikolay Samokhvalov <nik@postgres.ai> wrote:
On Wed, Jan 24, 2024 at 1:52 PM Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au> wrote:
That's right! There is no point in waiting for the official approval of the new RFC, which obviously will not change anything. I have been a contributor to this RFC for several years, and I can testify that every aspect imaginable has been thoroughly researched and agreed upon. Nothing new will definitely appear in the new RFC.

From a practical point of view, these two things are extremely important to have to support partitioning. It is better to implement limitations than throw them away.

Without them, this functionality will be of a very limited use in databases. We need to think about large tables – which means partitioning.

apologies -- this was a response to another email from you:

> "Other people" think that extracting the timestamp from UUIDv7 in violation of the new RFC, and generating UUIDv7 from the timestamp were both terrible and poorly thought out ideas. The authors of the new RFC had very good reasons to prohibit this. And the problems you face are the best confirmation of the correctness of the new RFC. It’s better to throw all this gag out of the official patch. Don't tempt developers to break the new RFC with these error-producing functions.
 

pgsql-hackers by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: Re: UUID v7
Next
From: Michael Paquier
Date:
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations