Date: Thu, 25 Jan 2024 08:09:18 +0000 (UTC)
From: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>
To: Nikolay Samokhvalov <nik@postgres.ai>,
	"Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
	Aleksander Alekseev <aleksander@timescale.com>,
	pgsql-hackers mailing list <pgsql-hackers@postgresql.org>,
	=?UTF-8?Q?Przemys=C5=82aw_Sztoch?= <przemyslaw@sztoch.pl>,
	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: <123941969.493601.1706170158988@mail.yahoo.com>
In-Reply-To: <00B784AB-5B52-4CC7-8A0D-B1C0C53B52DC@yandex-team.ru>
References: 
 <CAAhFRxitJv=yoGnXUgeLB_O+M7J2BJAmb5jqAT9gZ3bij3uLDA@mail.gmail.com>
 <3BDCCF0B-9C96-416C-87F6-071ABD7AED8B@yandex-team.ru>
 <3E7F8826-A275-44B6-A374-6E35B3B60AD5@yandex-team.ru>
 <CADsUR0CR7FioUWdA5QaVKij6_BE_en4tPA+pdCWQvN8hy0m+Pg@mail.gmail.com>
 <C80B8FDB-8D9E-48A2-82A2-48863987A1B1@yandex-team.ru>
 <CABw73UoHCDdzT=Yv5FkM-6F+ReHV4jaGVdzA-J6jN6FDQCZr2Q@mail.gmail.com>
 <CAGECzQQ3k66bnseNzTrvakjK7HRaL1k0LT+FEt0yjjVeZb8gjw@mail.gmail.com>
 <CAAhFRxj6Guh+_u+H7L_=VAJ5aeFTfH6Brb4OtCqu04xVHj29dg@mail.gmail.com>
 <6941A45B-C7D4-414B-A3A9-ACED172DFBD5@yandex-team.ru>
 <8DB43887-CA09-4845-83C0-33E8A79D0711@yandex-team.ru>
 <d9ac9cdc-8f2e-3794-f3b2-04f354e3b311@sztoch.pl>
 <CFE482C1-F001-4C51-89A3-084E7FF36157@yandex-team.ru>
 <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>
Subject: Re: UUID v7
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_493600_645006664.1706170158987"
Content-Length: 6091
Archived-At: 
 <https://www.postgresql.org/message-id/123941969.493601.1706170158988%40mail.yahoo.com>
Precedence: bulk

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

I am against turning the DBMS into another C++, in which they do not so muc=
h design something new as fix bugs in production after a crash.
As for partitioning, I already wrote to Andrey Borodin that we need a speci=
al function to generate a partition id using the UUIDv7 timestamp or even s=
imultaneously with the generation of the timestamp. For example, every mont=
h (or so, since precision is not needed here) a new partition is created. H=
ere's a good example: https://elixirforum.com/t/partitioning-postgres-table=
s-by-timestamp-based-uuids/60916
But without a separate function for extracting the entire timestamp from th=
e UUID! Let's solve this specific problem, and not give the developers a gr=
enade with the safety removed. Many developers have already decided to stor=
e the timestamp in UUIDv7, so as not to create a separate created_at field.=
 Then they will delete table records with the old timestamp, etc. Horrible =
mistakes are simply guaranteed.

Sergey Prokhorenko sergeyprokhorenko@yahoo.com.au=20

    On Thursday, 25 January 2024 at 09:51:58 am GMT+3, Andrey M. Borodin <x=
4mmm@yandex-team.ru> wrote: =20
=20
=20

> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov <nik@postgres.ai> wrote:
>=20
> 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 of=
f 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 <postgres@jeltef.nl> wrote:
>=20
> 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=
=E2=80=99s compose better error message?


Best regards, Andrey Borodin. =20
------=_Part_493600_645006664.1706170158987
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div class=3D"ydp5e414edfyahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px=
;"><div><div><div><div>I am against turning the DBMS into another C++, in w=
hich they do not so much design something new as fix bugs in production aft=
er a crash.</div><div><br></div><div>As for partitioning, I already wrote t=
o Andrey Borodin that we need a special function to generate a partition id=
 using the UUIDv7 timestamp or even simultaneously with the generation of t=
he timestamp. For example, every month (or so, since precision is not neede=
d here) a new partition is created. Here's a good example: https://elixirfo=
rum.com/t/partitioning-postgres-tables-by-timestamp-based-uuids/60916</div>=
<div><br></div><div>But without a separate function for extracting the enti=
re timestamp from the UUID! Let's solve this specific problem, and not give=
 the developers a grenade with the safety removed. Many developers have alr=
eady decided to store the timestamp in UUIDv7, so as not to create a separa=
te created_at field. Then they will delete table records with the old times=
tamp, etc. Horrible mistakes are simply guaranteed.</div></div><br></div><d=
iv><br></div><div class=3D"ydp5e414edfsignature">Sergey Prokhorenko sergeyp=
rokhorenko@yahoo.com.au</div></div>
        <div><br></div><div><br></div>
       =20
        </div><div id=3D"ydpe3b138abyahoo_quoted_6988694266" class=3D"ydpe3=
b138abyahoo_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 09:51:58 am GMT+3, Andr=
ey M. Borodin &lt;x4mmm@yandex-team.ru&gt; wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div dir=3D"ltr"><br clear=3D"none"><br clear=3D"none"=
>&gt; On 25 Jan 2024, at 09:40, Nikolay Samokhvalov &lt;<a shape=3D"rect" h=
ref=3D"mailto:nik@postgres.ai" rel=3D"nofollow" target=3D"_blank">nik@postg=
res.ai</a>&gt; wrote:<br clear=3D"none">&gt; <br clear=3D"none">&gt; 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 t=
hem away.<br clear=3D"none"><br clear=3D"none">Postgres always was a bit ha=
ckerish, allowing slightly more then is safe. I.e. you can define immutable=
 function that is not really immutable, turn off autovacuum or fsync. Why b=
other with safety guards here?<br clear=3D"none">My opinion is that we shou=
ld have this function to extract timestamp. Even if it can return strange v=
alues for imprecise RFC implementation.<br clear=3D"none"><br clear=3D"none=
"><br clear=3D"none">&gt; On 25 Jan 2024, at 02:15, Jelte Fennema-Nio &lt;<=
a shape=3D"rect" href=3D"mailto:postgres@jeltef.nl" rel=3D"nofollow" target=
=3D"_blank">postgres@jeltef.nl</a>&gt; wrote:<br clear=3D"none">&gt; <br cl=
ear=3D"none">&gt; So +1 for erroring when you provide a timestamp outside o=
f that range<br clear=3D"none">&gt; (either too far in the past or too far =
in the future).<br clear=3D"none"><br clear=3D"none"><br clear=3D"none">OK,=
 it seems like we have some consensus on ERRORing..<br clear=3D"none"><br c=
lear=3D"none">Do we have any other open items? Does v13 address all open it=
ems? Maybe let=E2=80=99s compose better error message?<br clear=3D"none"><b=
r clear=3D"none"><br clear=3D"none">Best regards, Andrey Borodin.</div></di=
v>
            </div>
        </div></body></html>
------=_Part_493600_645006664.1706170158987--