Horton

Re: UUID v7

Przemysław Sztoch <przemyslaw@sztoch.pl>

View thread View on postgr.es
From: Przemysław Sztoch <przemyslaw@sztoch.pl>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: pgsql-hackers mailing list <pgsql-hackers@postgresql.org>, Andrey Borodin <x4mmm@yandex-team.ru>, Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>, 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>
Date: 2024-01-16T21:09:56Z
Lists: pgsql-hackers 
> Another question: how did you choose between using TimestampTz and
> Timestamp types? I realize that internally it's all the same. Maybe
> Timestamp will be slightly better since the way it is displayed
> doesn't depend on the session settings. Many people I talked to find
> this part of TimestampTz confusing.
timstamptz internally always store UTC.
I believe that in SQL, when operating with time in UTC, you should 
always use timestamptz.
timestamp is theoretically the same thing. But internally it does not 
convert time to UTC and will lead to incorrect use.
-- 
Przemysław Sztoch | Mobile +48 509 99 00 66

Commits

  1. Fix timestamp overflow in UUIDv7 implementation.

  2. Add UUID version 7 generation function.

  3. Add some UUID support functions