| From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
|---|---|
| To: | pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Nick Babadzhanian <pgnickb(at)gmail(dot)com>, Mat Arye <mat(at)timescaledb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, "Kyzer Davis (kydavis)" <kydavis(at)cisco(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "brad(at)peabody(dot)io" <brad(at)peabody(dot)io>, Kirk Wolak <wolakk(at)gmail(dot)com> |
| Subject: | Re: UUID v7 |
| Date: | 2024-01-25 12:06:38 |
| Message-ID: | CAJ7c6TPX5xJSr17806LOGcvuM5kk3jEtRoHSmZkLuG52zYoZuA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. Even 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 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.
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.
--
Best regards,
Aleksander Alekseev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2024-01-25 12:29:24 | Re: Add bump memory context type and use it for tuplesorts |
| Previous Message | Amit Langote | 2024-01-25 11:54:25 | Re: remaining sql/json patches |