> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
> RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
> and now should be published.
It's RFC now.
https://datatracker.ietf.org/doc/rfc9562/
Best regards, Andrey Borodin.
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
Here's the documentation from ClickHouse [0] for their implementation. It's
identical to provided patch in this thread, with few notable exceptions:
1. Counter is 42 bits, not 18. The counter have no guard bits, every bit is
> On 13 Apr 2024, at 11:58, Andrey M. Borodin wrote:
>
> New UUID is assigned RFC number 9562, it was aproved by RFC editors and is
> now in AUTH48 state.
RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
and now should be published.
Best regards, Andrey
On Sat, Apr 13, 2024 at 07:07:34PM +, Sergey Prokhorenko wrote:
> I think that for the sake of such an epoch-making thing as UUIDv7 it
> would be worth slightly unfreezing this feature freeze.
A feature freeze is here to freeze things in place. This comes up
every year, and that won't
I think that for the sake of such an epoch-making thing as UUIDv7 it would be
worth slightly unfreezing this feature freeze.
Best regards,
Sergey prokhorenkosergeyprokhore...@yahoo.com.au
On Saturday, 13 April 2024 at 09:58:29 am GMT+3, Andrey M. Borodin
wrote:
> On 12 Mar
> On 12 Mar 2024, at 20:41, Jelte Fennema-Nio wrote:
>
> if e.g.
> the RFC got approved 2 weeks after Postgres its feature freeze
Jelte, you seem to be the visionary! I would consider participating in
lotteries or betting.
New UUID is assigned RFC number 9562, it was aproved by RFC editors
For every complex problem there is an answer that is clear, simple, and wrong.
Since the RFC allows microsecond timestamp granularity, the first thing that
comes to everyone's mind is to insert microsecond granularity into UUIDv7. And
if the RFC allowed nanosecond timestamp granularity, then
> On 4 Apr 2024, at 18:45, Peter Eisentraut wrote:
>
> On 26.03.24 18:26, Andrey M. Borodin wrote:
>>> Also, you are initializing 4 bits (I think?) to zero to guard against
>>> counter rollovers (so it's really just an 8 bit counter?). But nothing
>>> checks against such rollovers, so I
On 26.03.24 18:26, Andrey M. Borodin wrote:
Also, you are initializing 4 bits (I think?) to zero to guard against counter
rollovers (so it's really just an 8 bit counter?). But nothing checks against
such rollovers, so I don't understand the use of that.
No, there's only one guard rollover
des
>
> #include "access/xlog.h"
> #include "utils/builtins.h"
> #include "utils/datetime.h"
>
> are not needed.
>
> - The static variables sequence_counter and previous_timestamp could be kept
> inside the uuidv7() function.
Fixed.
Thanks!
Best regards, Andrey Borodin.
v24-0001-Implement-UUID-v7.patch
Description: Binary data
On 20.03.24 19:08, Andrey M. Borodin wrote:
On 19 Mar 2024, at 13:55, Peter Eisentraut wrote:
On 16.03.24 18:43, Andrey M. Borodin wrote:
On 15 Mar 2024, at 14:47, Aleksander Alekseev wrote:
+1 to the idea. I doubt that anyone will miss it.
PFA v22.
Changes:
1. Squashed all
Another source: Microservices Pattern: Database per service
|
|
|
| | |
|
|
|
| |
Microservices Pattern: Database per service
A service's database is private to that service
|
|
|
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Friday, 22 March 2024 at 04:58:59 pm
BTW: Each microservice should have its own database to ensure data isolation
and independence, enabling better scalability and fault tolerance
Source: Microservices Pattern: Shared database
|
|
| |
Microservices Pattern: Shared database
|
|
|
Sergey Prokhorenko
Why not use a single UUID generator for the database table in this case,
similar to autoincrement?
Sergey Prokhorenko
sergeyprokhore...@yahoo.com.au
On Friday, 22 March 2024 at 03:51:20 pm GMT+3, Peter Eisentraut
wrote:
On 21.03.24 16:21, Jelte Fennema-Nio wrote:
> On Wed, 20 Mar
On 21.03.24 16:21, Jelte Fennema-Nio wrote:
On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
Timer-based bits contribute to global sortability. But the real timers we have
are not even millisecond adjusted. We can hope for ~few ms variation in one
datacenter or in presence of atomic
I think it's better to leave Andrey's patch as is, and add another function in
the future with a customizable UUIDv7 structure for special use cases. The
structure description can be in JSON format. See this discussion.
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Friday, 22
> On 21 Mar 2024, at 20:21, Jelte Fennema-Nio wrote:
>
> On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
>> Timer-based bits contribute to global sortability. But the real timers we
>> have are not even millisecond adjusted. We can hope for ~few ms variation in
>> one datacenter or
On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
> Timer-based bits contribute to global sortability. But the real timers we
> have are not even millisecond adjusted. We can hope for ~few ms variation in
> one datacenter or in presence of atomic clocks.
I think the main benefit of using
wards.
I think that microseconds are good only for hardware-specific solutions, not
for something that runs on variety of platforms, OSes, devices.
Best regards, Andrey Borodin.
v23-0001-Implement-UUID-v7.patch
Description: Binary data
On 16.03.24 18:43, Andrey M. Borodin wrote:
On 15 Mar 2024, at 14:47, Aleksander Alekseev wrote:
+1 to the idea. I doubt that anyone will miss it.
PFA v22.
Changes:
1. Squashed all editorialisation by Jelte
2. Fixed my erroneous comments on using Method 2 (we are using method 1 instead)
3.
e all traces of uuid_extract_variant()
Thanks!
Best regards, Andrey Borodin.
v22-0001-Implement-UUID-v7.patch
Description: Binary data
Hi,
> > So maybe we don't need the _extract_variant function?
>
> I think it's the best possible solution. The variant has no value besides
> detecting if a version can be extracted.
+1 to the idea. I doubt that anyone will miss it.
--
Best regards,
Aleksander Alekseev
> On 14 Mar 2024, at 20:10, Peter Eisentraut wrote:
>
> I think the behavior of uuid_extract_var(iant) is wrong. The code
> takes just two bits to return, but the draft document is quite clear
> that the variant is 4 bits (see Table 1).
Well, it was correct only for
On 14.03.24 12:25, Andrey M. Borodin wrote:
I think the behavior of uuid_extract_var(iant) is wrong. The code
takes just two bits to return, but the draft document is quite clear
that the variant is 4 bits (see Table 1).
Well, it was correct only for implemented variant. I've made version that
> On 14 Mar 2024, at 16:07, Peter Eisentraut wrote:
>
> On 10.03.24 13:59, Andrey M. Borodin wrote:
>>> The functions uuid_extract_ver and uuid_extract_var could be named
>>> uuid_extract_version and uuid_extract_variant. Otherwise, it's hard
>>> to tell them apart, with only one letter
On 10.03.24 13:59, Andrey M. Borodin wrote:
The functions uuid_extract_ver and uuid_extract_var could be named
uuid_extract_version and uuid_extract_variant. Otherwise, it's hard
to tell them apart, with only one letter different.
Renamed.
Another related comment: Throughout your patch,
On Tue, 12 Mar 2024 at 18:18, Sergey Prokhorenko
wrote:
> Andrey and you simply did not read the RFC a little further down in the text:
You're totally right, sorry about that. Maybe it would be good to move
those subsections around a bit in the RFC though, so that anything
related to only one
Hi Jelte,
I am one of the contributors to this RFC.
Andrey's patch corresponds exactly to Fixed-Length Dedicated Counter Bits
(Method 1).
Andrey and you simply did not read the RFC a little further down in the text:
__
The
On Tue, 12 Mar 2024 at 07:32, Michael Paquier wrote:
> Sure, there is no problem in discussing a patch to implement a
> behavior. But I disagree about taking a risk in merging something
> that could become non-compliant with the approved RFC, if the draft is
> approved at the end, of course.
On Mon, 11 Mar 2024 at 19:27, Andrey M. Borodin wrote:
> Sorry for this long and vague explanation, if it still seems too uncertain we
> can have a chat or something like that. I don't think this number picking
> stuff deserve to be commented, because it still is quite close to random. RFC
>
On Tue, Mar 12, 2024 at 11:10:37AM +0500, Andrey M. Borodin wrote:
> On 12 Mar 2024, at 10:53, Michael Paquier wrote:
>> On 22 Jan 2024, at 09:22, Nikolay Samokhvalov wrote:
>>
>> And many libraries are already including implementation of UUIDv7 – here are
>> some examples:
>>
>> -
> On 12 Mar 2024, at 10:53, Michael Paquier wrote:
>
> It does not strike me as a good idea to rush an implementation without
> a specification officially approved because there is always a risk of
> shipping something that's non-compliant into core. But perhaps I am
> missing something on
On Mon, Mar 11, 2024 at 11:27:43PM +0500, Andrey M. Borodin wrote:
> Sorry for this long and vague explanation, if it still seems too
> uncertain we can have a chat or something like that. I don't think
> this number picking stuff deserve to be commented, because it still
> is quite close to
> On 11 Mar 2024, at 20:56, Jelte Fennema-Nio wrote:
>
> Attached a few comment fixes/improvements and a pgindent run (patch 0002-0004)
Thanks!
> Now with the added comments, one thing pops out to me: The comments
> mention that we use "Monotonic Random", but when I read the spec that
>
he extra rand_b bits for
this. The spec says we MAY, but it does remove the amount of
randomness in our UUIDs.
v21-0001-Implement-UUID-v7.patch
Description: Binary data
v21-0003-Run-pgindent.patch
Description: Binary data
v21-0005-Change-to-Fixed-Length-Dedicated-Counter-Bits.patch
Description: Binary data
v
h LGTM. I think it could be merged unless there are any open
issues left. I don't think so, but maybe I missed something.
--
Best regards,
Aleksander Alekseev
v20-0001-Implement-UUID-v7.patch
Description: Binary data
tests.
Thanks!
Best regards, Andrey Borodin.
v19-0001-Implement-UUID-v7.patch
Description: Binary data
oncurrent sessions or between restarts? Maybe the counter or random
> stuff does that, but it's not explained.
I think restart takes more than 1ms, so this is covered with time tick.
I've added paragraph about frequency of generation in uuidv7() header.
Best regards, Andrey Borodin.
v18-0001-Implement-UUID-v7.patch
Description: Binary data
On 30.01.24 14:35, Andrey M. Borodin wrote:
On 30 Jan 2024, at 15:33, Junwang Zhao wrote:
It's always good to add a newline at the end of a source file, though
this might be nitpicky.
Thanks, also fixed warning found by CFBot.
I have various comments on this patch:
-
typo:
being carried to time step
should be:being carried to timestemp
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Tuesday, 30 January 2024 at 04:35:45 pm GMT+3, Andrey M. Borodin
wrote:
> On 30 Jan 2024, at 15:33, Junwang Zhao wrote:
>
> It's always good to add a
> On 30 Jan 2024, at 15:33, Junwang Zhao wrote:
>
> It's always good to add a newline at the end of a source file, though
> this might be nitpicky.
Thanks, also fixed warning found by CFBot.
Best regards, Andrey Borodin.
v17-0001-Implement-UUID-v7.patch
Description: Binary data
Hi Andrey,
On Tue, Jan 30, 2024 at 5:56 PM Andrey M. Borodin wrote:
>
>
>
> > On 30 Jan 2024, at 12:28, Sergey Prokhorenko
> > wrote:
> >
> >
> > I think this phrase is outdated: "This function can optionally accept a
> > timestamp used instead of current time.
> > This allows implementation
t's possible that some UUIDs will store a time that is
> slightly later
> + than their actual generation time
I’ve rewritten this phrase, hope it’s more clear now.
Best regards, Andrey Borodin.
v16-0001-Implement-UUID-v7.patch
Description: Binary data
Andrey,
I think this phrase is outdated: "This function can optionally accept a
timestamp used instead of current time.This allows implementation of k-way
sotable identifiers."
This phrase is wrong: "Both functions return a version 4 (random) UUID."
For this phrase the reason is unclear and the
ation addons.
Thanks!
Best regards, Andrey Borodin.
v15-0001-Implement-UUID-v7.patch
Description: Binary data
Andrey,
I understand and agree with your goals. But instead of dangerous universal
functions, it is better to develop safe highly specialized functions that
implement only these goals.
There should not be a function uuidv7(T) from an arbitrary timestamp, but there
should be a special function
On Mon, 29 Jan 2024 at 19:32, Andrey M. Borodin wrote:
> Even if the developer pass constant time to uuidv7(T) they will get what they
> asked for - unique identifier. Moreover - it still will be keeping locality.
> There will be no negative consequences at all.
It will be significantly "less
> On 25 Jan 2024, at 22:04, Sergey Prokhorenko
> wrote:
>
> Aleksander,
>
> In this case the documentation must state that the functions
> uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
> developers may use these functions with caution at their own risk, and
On Mon, Jan 29, 2024 at 7:38 PM Jelte Fennema-Nio wrote:
>
> tl;dr I believe we should remove the uuidv7(timestamp) function from
> this patchset.
>
> On Thu, 25 Jan 2024 at 18:04, Sergey Prokhorenko
> wrote:
> > In this case the documentation must state that the functions
> >
On Thu, 25 Jan 2024 at 13:31, Aleksander Alekseev
wrote:
> PFA v14.
+uuidv4 () uuid
+
+ Both functions return a version 4 (random) UUID. This is the most commonly
+ used type of UUID and is appropriate when random distribution of keys does
+ not affect performance of an application.
+
tl;dr I believe we should remove the uuidv7(timestamp) function from
this patchset.
On Thu, 25 Jan 2024 at 18:04, Sergey Prokhorenko
wrote:
> In this case the documentation must state that the functions
> uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
> developers
By the way, the Go language has also already implemented a function for UUIDv7:
https://pkg.go.dev/github.com/gofrs/uuid#NewV7
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Thursday, 25 January 2024 at 12:49:46 am GMT+3, Sergey Prokhorenko
wrote:
That's right! There is no
Aleksander,
In this case the documentation must state that the functions
uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
developers may use these functions with caution at their own risk, and these
functions are not recommended for production environment.
The
Hi,
> 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.
PFA v14. I changed:
```
elog(ERROR, "Time argument of UUID v7 cannot exceed 6 bytes");
```
...
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
Andrey M. Borodin wrote on 25.01.2024 07:51:
On 25 Jan 2024, at 09:40, Nikolay Samokhvalov 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
I am against turning the DBMS into another C++, in which they do not so much
design something new as fix bugs in production after a crash.
As for partitioning, I already wrote to Andrey Borodin that we need a special
function to generate a partition id using the UUIDv7 timestamp or even
> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov 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
On Wed, Jan 24, 2024 at 8:40 PM Nikolay Samokhvalov wrote:
> On Wed, Jan 24, 2024 at 1:52 PM Sergey Prokhorenko <
> sergeyprokhore...@yahoo.com.au> wrote:
>
>> That's right! There is no point in waiting for the official approval of
>> the new RFC, which obviously will not change anything. I have
On Wed, Jan 24, 2024 at 1:52 PM Sergey Prokhorenko <
sergeyprokhore...@yahoo.com.au> wrote:
> That's right! There is no point in waiting for the official approval of
> the new RFC, which obviously will not change anything. I have been a
> contributor to this RFC
>
That's right! There is no point in waiting for the official approval of the new
RFC, which obviously will not change anything. I have been a contributor to
this RFC for several years, and I can testify that every aspect imaginable has
been thoroughly researched and agreed upon. Nothing new will
"Other people" think that extracting the timestamp from UUIDv7 in violation of
the new RFC, and generating UUIDv7 from the timestamp were both terrible and
poorly thought out ideas. The authors of the new RFC had very good reasons to
prohibit this. And the problems you face are the best
On Wed, 24 Jan 2024 at 21:47, Marcos Pegoraro wrote:
>
> I understand your point, but
> '2000-01-01' :: timestamp and '1900-01-01' :: timestamp are both valid
> timestamps.
>
> So looks strange if user can do
> select uuidv7(TIMESTAMP '2000-01-01')
> but cannot do
> select uuidv7(TIMESTAMP
I understand your point, but
'2000-01-01' :: timestamp and '1900-01-01' :: timestamp are both valid
timestamps.
So looks strange if user can do
select uuidv7(TIMESTAMP '2000-01-01')
but cannot do
select uuidv7(TIMESTAMP '1900-01-01')
Regards
Marcos
Em qua., 24 de jan. de 2024 às 14:51, Andrey
> On 24 Jan 2024, at 22:00, Marcos Pegoraro wrote:
>
> Is enough from 1970 ?
Per standard unix_ts_ms field is a number of milliseconds from UNIX start date
1970-01-01.
> How about if user wants to have an UUID of his birth date ?
I've claimed my
0078c135-bd00-70b1-865a-63c3741922a5
But
Only the
> > fact that timestamp from the far past generates UUID from the future
> > bothers me.
>
> PFA implementation of guard checks, but I'm afraid that this can cause
> failures in ID generation unexpected to the user...
> See tests
>
> +-- errors in edge c
user...
See tests
+-- errors in edge cases of UUID v7
+SELECT 1 FROM uuidv7('1970-01-01 00:00:00+00'::timestamptz - interval '0ms');
+SELECT uuidv7('1970-01-01 00:00:00+00'::timestamptz - interval '1ms'); --
ERROR expected
+SELECT 1 FROM
uuidv7(uuid_extract_time('--7FFF-B000-00
Hi,
> Also, please not that uuidv7(time+1us) and uuidv7(time) will have the same
> internal timestamp, so despite time+1us > time, still second uuid will be
> greater.
>
> Both invariants you proposed cannot be reasonably guaranteed. Upholding any
> of them greatly reduces
w()) will always ERROR-out.
Standard implies more coarse-grained timestamp that we have.
Also, please not that uuidv7(time+1us) and uuidv7(time) will have the same
internal timestamp, so despite time+1us > time, still second uuid will be
greater.
Both invariants you proposed cannot be reasonably guaranteed. Upholding any of
them greatly reduces usability of UUID v7.
Best regards, Andrey Borodin.
Hi,
> Function to extract timestamp does not provide any guarantees at all.
> Standard states this, see Kyzer answers upthread.
> Moreover, standard urges against relying on that if uuidX was generated
> before uuidY, then uuidX happen, but does not guaranty that.
> All what is guaranteed is
Hi,
> Values that violate named invariants should be rejected with an error.
To clarify, I don't think we should bother about the precision part.
"Equals" in the example above means "equal within UUIDv7 precision",
same for "more" and "less". However, years 2977 BC and 5943 AC are
clearly not
> On 24 Jan 2024, at 18:02, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> UUIDv7 range does not correspond to timestamp range. But it’s purpose is not
>> in storing timestamp, but in being unique identifier. So I don’t think it
>> worth throwing an error when overflowing value is given. BTW
Hi,
> UUIDv7 range does not correspond to timestamp range. But it’s purpose is not
> in storing timestamp, but in being unique identifier. So I don’t think it
> worth throwing an error when overflowing value is given. BTW if you will
> subtract some nanoseconds - you will not get back
> On 24 Jan 2024, at 17:31, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> Cfbot also seems to be happy with the patch so I'm changing the CF
>> entry status to RfC.
>
> I've found a bug:
>
> ```
> =# select now() - interval '5000 years';
>?column?
>
Hi,
> Cfbot also seems to be happy with the patch so I'm changing the CF
> entry status to RfC.
I've found a bug:
```
=# select now() - interval '5000 years';
?column?
2977-01-24 15:29:01.779462+02:30:17 BC
Time: 0.957 ms
=# select
Hi,
> But now (after big timeseries project with multiple time zones and DST
> problems) I think differently.
> Even though timestamp and timestamptz are practically the same, timestamptz
> should be used to store the time in UTC.
> Choosing timestamp is more likely to lead to problems and
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Manually tested uuidv7(), uuid_extract_time() – they work as
On Fri, Jan 19, 2024 at 10:07 AM Andrey Borodin
wrote:
>
>
> > On 19 Jan 2024, at 13:25, Andrey Borodin wrote:
> >
> > Also, I've added some documentation on all functions.
>
> Here's v12. Changes:
> 1. Documentation improvements
> 2. Code comments
> 3. Better commit message and reviews list
>
> On 19 Jan 2024, at 13:25, Andrey Borodin wrote:
>
> Also, I've added some documentation on all functions.
Here's v12. Changes:
1. Documentation improvements
2. Code comments
3. Better commit message and reviews list
Best regards, Andrey Borodin.
v12-0001-Implement-UUID
Hi,
> No.
>
> Timestamp and TimestampTz are absolutely the same thing. The only
> difference is how they are shown to the user. TimestampTz uses session
> context in order to be displayed in the TZ chosen by the user. Thus
> typically it is somewhat more confusing to the users and thus I asked
>
ind of confusing behaviour.
I've changed it to more expected version.
Also, I've added some documentation on all functions.
Best regards, Andrey Borodin.
v11-0001-Implement-UUID-v7-as-per-IETF-draft.patch
Description: Binary data
On Thu, Jan 18, 2024 at 11:31 AM Andrey Borodin
wrote:
>
> Now I'm completely lost in time... I've set local time to NY (UTC-5).
>
> postgres=# select TIMESTAMP WITH TIME ZONE '2022-02-22 14:22:22-05' -
> TIMESTAMP WITH TIME ZONE 'Tuesday, February 22, 2022 2:22:22.00 PM
> GMT-05:00';
>
On Thu, Jan 18, 2024 at 5:18 AM Andrey Borodin wrote:
> Current patch version attached. I've addressed all other requests:
> function renames, aliases, multiple functions instead of optional params,
> cleaner catalog definitions, not throwing error when [var,ver,time] value
> is unknown.
> What
We are not allowed to consider any time other than UTC.
You need to write to the authors of the standard. I suppose this is a
mistake.
I know from experience that errors in such standards most often appear
in examples.
Nobody detects them at first.
Everyone reads and checks ideas, not
Aleksander Alekseev wrote on 1/18/2024 3:20 PM:
Hi,
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.
Using localtime would be absurd. Especially since time goes back during
summer time change.
I believe our implementation should use UTC. No one forbids us from
assuming that our local time for generating uuid is UTC.
Andrey Borodin wrote on 1/18/2024 2:17 PM:
On 17 Jan 2024, at 02:19, Jelte
Hi Andrey,
You'd better generate a test UUIDv7 for midnight 1 Jan 1970 UTC. In this case,
the timestamp in UUIDv7 according to the new RFC must be filled with zeros. By
extracting the timestamp from this test UUIDv7, you should get exactly midnight
1 Jan 1970 UTC.
I also recommend this
> On 18 Jan 2024, at 20:39, Andrey Borodin wrote:
>
> But 16455577420ns after 1582-10-15 00:00:00 UTC was 2022-02-22 19:22:22
> UTC. And that was 2022-02-23 00:22:22 in UTC-05.
'2022-02-22 19:22:22 UTC' is exactly that moment which was encoded into example
UUIDs. It's not
Hi Andrey,
Aleksander Alekseev wrote: "If this is the case, I think the example is indeed
wrong".
This is one of the reasons why I was categorically against any examples of
implementation in the new RFC. The examples have been very poorly studied and
discussed, and therefore it is better not
Hi Andrey,
> > Timestamp and TimestampTz are absolutely the same thing.
> My question is not about Postgres data types. I'm asking about examples in
> the standard.
>
> There's an example 017F22E2-79B0-7CC3-98C4-DC0C0C07398F. It is expected to be
> generated on "Tuesday, February 22, 2022
> On 18 Jan 2024, at 19:20, Aleksander Alekseev
> wrote:
>
> Timestamp and TimestampTz are absolutely the same thing.
My question is not about Postgres data types. I'm asking about examples in the
standard.
There's an example 017F22E2-79B0-7CC3-98C4-DC0C0C07398F. It is expected to be
Hi,
> 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
own.
What is left: deal with timezones, improve documentation.
Best regards, Andrey Borodin.
[0]
https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis#name-example-of-a-uuidv1-value
v10-0001-Implement-UUID-v7-as-per-IETF-draft.patch
Description: Binary data
On Tue, 16 Jan 2024 at 22:02, Przemysław Sztoch wrote:
> But replace uuidv7_extract_time(uuid) with uuid_extract_time(uuid) - function
> should be able extract timestamp from v1/v6/v7
I'm fine with this.
> I would highly recommend to add:
> uuidv5(namespace uuid, name text) -> uuid
> using
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
Jelte Fennema-Nio wrote on 1/16/2024 9:25 PM:
On Tue, 16 Jan 2024 at 19:17, Andrey M. Borodin wrote:
So currently my preference for the function names would be:
- uuidv4() -> alias for gen_random_uuid()
- uuidv7()
- uuidv7(timestamptz)
- uuid_extract_ver(uuid)
- uuid_extract_var(uuid)
-
On Tue, 16 Jan 2024 at 19:17, Andrey M. Borodin wrote:
> Jelte, what is your opinion on naming the function which extracts timestamp
> from UUID v7?
I looked at a few more datatypes: json, jsonb & hstore. The get_
prefix is not used there at all, so I'm still opposed to that. But
Andrey Borodin wrote on 1/16/2024 1:15 PM:
Sergey, Przemysław, Jelte, thanks for your feedback.
Here's v9. Changes:
1. Swapped type of the argument to timestamptz in gen_uuid_v7()
Please update docs part about optional timestamp argument.
2. Renamed get_uuid_v7_time() to uuid_v7_time()
On Tue, 16 Jan 2024 at 15:44, Andrey M. Borodin wrote:
> > On 16 Jan 2024, at 18:00, Aleksander Alekseev
> > wrote:
> > Not 100% sure what this is for. Any chance this could be part of another
> > patch?
> Nope, it’s necessary there. Without these changes catalog functions cannot
> have
, adding prepositions.
Previously, Jelte had some thoughts on idiomatic function names.
Jelte, what is your opinion on naming the function which extracts timestamp
from UUID v7?
Of cause, it would be great to hear opinion from anyone else.
Best regards, Andrey Borodin.
1 - 100 of 134 matches
Mail list logo
