public inbox for [email protected]
help / color / mirror / Atom feedFrom: Przemysław Sztoch <[email protected]>
To: Andrey M. Borodin <[email protected]>
Cc: Nikolay Samokhvalov <[email protected]>
Cc: Sergey Prokhorenko <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers mailing list <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Nick Babadzhanian <[email protected]>
Cc: Mat Arye <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Nikolay Samokhvalov <[email protected]>
Cc: Kyzer Davis (kydavis) <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Kirk Wolak <[email protected]>
Subject: Re: UUID v7
Date: Thu, 25 Jan 2024 12:14:38 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAAhFRxitJv=yoGnXUgeLB_O+M7J2BJAmb5jqAT9gZ3bij3uLDA@mail.gmail.com>
<CAGECzQQ=38bVUR=LZ6vmBCEjaDfOOoQa+ygFJ1mCG_H2jsC90Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAJ7c6TPcYQHWYa97MiETT6O8=3Yq=r0CMtyu0y3DEYmOcmnmPA@mail.gmail.com>
<[email protected]>
<CAJ7c6TPZZg8uM+2=Hj_s-gcvYCfYo=8ABZPTBvvh=mkCdRot9Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAKFQuwai1N+Tm-P91zqnJEmT11kD7RqJLJrrhWFSxS1pRSR47w@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAM527d__3qQxvpUC_5tWW5TeodE=bivYT3eNDpjrVAk3-uU0TA@mail.gmail.com>
<[email protected]>
<CAM527d8QbYa9CfsUezn_owUP8M0JWGYiosMEOkQqD6=PsncEnA@mail.gmail.com>
<[email protected]>
Andrey M. Borodin wrote on 25.01.2024 07:51:
>
>> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov <[email protected]> wrote:
>>
>> 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.
> Postgres always was a bit hackerish, allowing slightly more then is safe. I.e. you can define immutable function that is not really immutable, turn off autovacuum or fsync. Why bother with safety guards here?
> My opinion is that we should have this function to extract timestamp. Even if it can return strange values for imprecise RFC implementation.
>
>
>> On 25 Jan 2024, at 02:15, Jelte Fennema-Nio <[email protected]> wrote:
>>
>> So +1 for erroring when you provide a timestamp outside of that range
>> (either too far in the past or too far in the future).
>
> OK, it seems like we have some consensus on ERRORing..
>
> Do we have any other open items? Does v13 address all open items? Maybe let’s compose better error message?
+1 for erroring when ts is outside range.
v13 looks good for me. I think we have reached a optimal compromise.
--
Przemysław Sztoch | Mobile +48 509 99 00 66
view thread (69+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: UUID v7
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox