From: | Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | 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>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>, 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 11:14:38 |
Message-ID: | f0c8f561-9f68-0634-b815-33a629c352ec@sztoch.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrey M. Borodin wrote on 25.01.2024 07:51:
>
>> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov <nik(at)postgres(dot)ai> 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 <postgres(at)jeltef(dot)nl> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-01-25 11:32:34 | Re: Fix inappropriate comments in function ReplicationSlotAcquire |
Previous Message | Bharath Rupireddy | 2024-01-25 10:57:20 | Re: A failure in t/038_save_logical_slots_shutdown.pl |