Date: Thu, 25 Jan 2024 17:04:05 +0000 (UTC)
From: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>
To: pgsql-hackers mailing list <pgsql-hackers@postgresql.org>,
	Aleksander Alekseev <aleksander@timescale.com>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
	=?UTF-8?Q?Przemys=C5=82aw_Sztoch?= <przemyslaw@sztoch.pl>,
	Nikolay Samokhvalov <nik@postgres.ai>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	Jelte Fennema-Nio <postgres@jeltef.nl>,
	Nick Babadzhanian <pgnickb@gmail.com>,
	Mat Arye <mat@timescaledb.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Daniel Gustafsson <daniel@yesql.se>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Nikolay Samokhvalov <samokhvalov@gmail.com>,
	"Kyzer Davis (kydavis)" <kydavis@cisco.com>,
	Andres Freund <andres@anarazel.de>,
	"brad@peabody.io" <brad@peabody.io>, Kirk Wolak <wolakk@gmail.com>
Message-ID: <1014147035.642629.1706202245918@mail.yahoo.com>
In-Reply-To: 
 <CAJ7c6TPX5xJSr17806LOGcvuM5kk3jEtRoHSmZkLuG52zYoZuA@mail.gmail.com>
References: 
 <CAAhFRxitJv=yoGnXUgeLB_O+M7J2BJAmb5jqAT9gZ3bij3uLDA@mail.gmail.com>
 <CAGECzQQ=38bVUR=LZ6vmBCEjaDfOOoQa+ygFJ1mCG_H2jsC90Q@mail.gmail.com>
 <1003561938.6914482.1704452267331@mail.yahoo.com>
 <80E8F728-FC9C-461E-9B61-332E3AAEC066@yandex-team.ru>
 <CAJ7c6TPcYQHWYa97MiETT6O8=3Yq=r0CMtyu0y3DEYmOcmnmPA@mail.gmail.com>
 <67eb8a02-f35c-af10-1615-afae0f9f7548@sztoch.pl>
 <CAJ7c6TPZZg8uM+2=Hj_s-gcvYCfYo=8ABZPTBvvh=mkCdRot9Q@mail.gmail.com>
 <8A52AED1-2CA6-403C-8B5B-D24EA8D58616@yandex-team.ru>
 <9CE1E513-B11A-4C59-980E-D61EC56716E7@yandex-team.ru>
 <CAKFQuwai1N+Tm-P91zqnJEmT11kD7RqJLJrrhWFSxS1pRSR47w@mail.gmail.com>
 <B4034B63-6C3F-46B1-A26F-23B4B8CC72D6@yandex-team.ru>
 <0A0D7507-C434-46AC-BCC4-1166C5A2742A@yandex-team.ru>
 <CAM527d__3qQxvpUC_5tWW5TeodE=bivYT3eNDpjrVAk3-uU0TA@mail.gmail.com>
 <1459150585.359059.1706132985954@mail.yahoo.com>
 <CAM527d8QbYa9CfsUezn_owUP8M0JWGYiosMEOkQqD6=PsncEnA@mail.gmail.com>
 <00B784AB-5B52-4CC7-8A0D-B1C0C53B52DC@yandex-team.ru>
 <f0c8f561-9f68-0634-b815-33a629c352ec@sztoch.pl>
 <CAJ7c6TPX5xJSr17806LOGcvuM5kk3jEtRoHSmZkLuG52zYoZuA@mail.gmail.com>
Subject: Re: UUID v7
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_642628_1369770526.1706202245917"
Content-Length: 7147
Archived-At: 
 <https://www.postgresql.org/message-id/1014147035.642629.1706202245918%40mail.yahoo.com>
Precedence: bulk

------=_Part_642628_1369770526.1706202245917
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Aleksander,

In this case=C2=A0the documentation must state that the functions uuid_extr=
act_time() and uuidv7(T) are against the=C2=A0RFC requirements, and that de=
velopers may use these functions with caution at their own risk, and these=
=C2=A0functions are not recommended for production environment.

The function=C2=A0uuidv7(T) is not better than=C2=A0uuid_extract_time().=C2=
=A0Careless developers may well pass any business date into this function: =
document date, registration date, payment date, reporting date, start date =
of the current month, data download date, and even a constant. This would b=
e a profanation of UUIDv7 with very negative consequences.

Sergey Prokhorenkosergeyprokhorenko@yahoo.com.au=20

    On Thursday, 25 January 2024 at 03:06:50 pm GMT+3, Aleksander Alekseev =
<aleksander@timescale.com> wrote: =20
=20
 Hi,

> 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. Eve=
n if it can return strange values for imprecise RFC implementation.

Completely agree.

Users that don't like or don't need it can pretend there are no
uuid_extract_time() and uuidv7(T) in Postgres. If we don't provide
them however, users that need them will end up writing their own
probably buggy and not compatible implementations. That would be much
worse.

> 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 l=
et=E2=80=99s 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.

Andrey, many thanks for the updated patch.

LGTM, cfbot is happy and I don't think we have any open items left. So
changing CF entry status back to RfC.

--=20
Best regards,
Aleksander Alekseev
 =20
------=_Part_642628_1369770526.1706202245917
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div class=3D"ydpcfb74b31yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px=
;"><div><div dir=3D"ltr" data-setdir=3D"false"><span><span><span style=3D"c=
olor: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-=
serif;">Aleksander,</span></span><br></span></div><div dir=3D"ltr" data-set=
dir=3D"false"><span><br></span></div><div dir=3D"ltr" data-setdir=3D"false"=
><span><span>In this case</span>&nbsp;the documentation must state that the=
 functions uuid_extract_time() and uuidv7(T) <span>are against the</span>&n=
bsp;RFC requirements, and that developers may use these functions with caut=
ion at their own risk, and these&nbsp;<span><span style=3D"color: rgb(0, 0,=
 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: =
16px;">functions are not recommended for <span>production environment</span=
>.</span></span></span><br></div><div dir=3D"ltr" data-setdir=3D"false"><sp=
an><br></span></div><div dir=3D"ltr" data-setdir=3D"false"><span>The functi=
on&nbsp;<span><span style=3D"color: rgb(0, 0, 0); font-family: Helvetica Ne=
ue, Helvetica, Arial, sans-serif; font-size: 16px;">uuidv7(T) is not better=
 than&nbsp;<span><span style=3D"color: rgb(0, 0, 0); font-family: Helvetica=
 Neue, Helvetica, Arial, sans-serif; font-size: 16px;">uuid_extract_time().=
&nbsp;<span>Careless developers may well pass any business date into this f=
unction: document date, registration date, payment date, reporting date, st=
art date of the current month, data download date, and even a constant. Thi=
s would be a profanation of UUIDv7 with very negative consequences.</span><=
/span></span></span></span></span></div><div dir=3D"ltr" data-setdir=3D"fal=
se"><span><br></span></div><div dir=3D"ltr" data-setdir=3D"false"><br></div=
><div class=3D"ydpcfb74b31signature">Sergey Prokhorenko</div><div class=3D"=
ydpcfb74b31signature">sergeyprokhorenko@yahoo.com.au</div></div>
        <div><br></div><div><br></div>
       =20
        </div><div id=3D"ydpf6fddb82yahoo_quoted_6994634651" class=3D"ydpf6=
fddb82yahoo_quoted">
            <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
               =20
                <div>
                    On Thursday, 25 January 2024 at 03:06:50 pm GMT+3, Alek=
sander Alekseev &lt;aleksander@timescale.com&gt; wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div dir=3D"ltr">Hi,<br clear=3D"none"><br clear=3D"no=
ne">&gt; Postgres always was a bit hackerish, allowing slightly more then i=
s safe. I.e. you can define immutable function that is not really immutable=
, turn off autovacuum or fsync. Why bother with safety guards here?<br clea=
r=3D"none">&gt; My opinion is that we should have this function to extract =
timestamp. Even if it can return strange values for imprecise RFC implement=
ation.<br clear=3D"none"><br clear=3D"none">Completely agree.<br clear=3D"n=
one"><br clear=3D"none">Users that don't like or don't need it can pretend =
there are no<br clear=3D"none">uuid_extract_time() and uuidv7(T) in Postgre=
s. If we don't provide<br clear=3D"none">them however, users that need them=
 will end up writing their own<br clear=3D"none">probably buggy and not com=
patible implementations. That would be much<br clear=3D"none">worse.<div cl=
ass=3D"ydpf6fddb82yqt4291036767" id=3D"ydpf6fddb82yqtfd69326"><br clear=3D"=
none"><br clear=3D"none">&gt; So +1 for erroring when you provide a timesta=
mp outside of that range<br clear=3D"none">&gt; (either too far in the past=
 or too far in the future).<br clear=3D"none">&gt;<br clear=3D"none">&gt; O=
K, it seems like we have some consensus on ERRORing..<br clear=3D"none">&gt=
;<br clear=3D"none">&gt; Do we have any other open items? Does v13 address =
all open items? Maybe let=E2=80=99s compose better error message?<br clear=
=3D"none">&gt;<br clear=3D"none">&gt; +1 for erroring when ts is outside ra=
nge.<br clear=3D"none">&gt;<br clear=3D"none">&gt; v13 looks good for me. I=
 think we have reached a optimal compromise.</div><br clear=3D"none"><br cl=
ear=3D"none">Andrey, many thanks for the updated patch.<br clear=3D"none"><=
br clear=3D"none">LGTM, cfbot is happy and I don't think we have any open i=
tems left. So<br clear=3D"none">changing CF entry status back to RfC.<br cl=
ear=3D"none"><br clear=3D"none">-- <br clear=3D"none">Best regards,<br clea=
r=3D"none">Aleksander Alekseev<div class=3D"ydpf6fddb82yqt4291036767" id=3D=
"ydpf6fddb82yqtfd47766"><br clear=3D"none"></div></div></div>
            </div>
        </div></body></html>
------=_Part_642628_1369770526.1706202245917--