Add to core ?

[anayrat]

Hello,

Thanks for your work on this subject !

Do you plan to propose to postgres hackers as a core functionality or contrib ?

I am afraid, if it is not in the core or contrib, user will be reluctant to use this. We want to be sure this feature will be available in the future, and we are not tied to an extension.

Thanks!

[Tostino]

Just wanted to echo the pain I am going through simply because this is an extension and i'm trying to get it into my a docker image.

[tvondra]

I haven't really thought about getting this into core, for a couple reasons.

1) strong pushback to adding more and more stuff to contrib - there's about a zillion other packages that might be just as useful, and we can't really include all of them. Every package means we need to maintain it, etc.

2) it ties the release cycles - Including it into contrib means we couldn't introduce new features on stable releases, and can't fix bugs between outside a PG minor. Admittedly, there wasn't much development activity on this.

These two issues are pretty much why we have extensions - to allow packages developed and released independently. Adding it to contrib would defeat some of this, unfortunately.

If you want to propose / advocate for including it on pgsql-hackers, be my guest.

But I think it's unlikely to be successful in this extension form. Maybe if it was reworked as an uuid-ossp improvement, adding the new UUID versions (https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-04.html#name-introduction-2) which are however still in draft, AFAICS.

Note: This is somewhat different from the new UUID versions, because of the cycling. But maybe that could be still included as an optional feature.

[tvondra]

I'm not a docker expert - can you elaborate on what's the issue with using this in a docker image?

BTW there's a RPM in the community yum repository (https://download.postgresql.org/pub/repos/yum/15/redhat/rhel-9-x86_64/sequential_uuids_15-1.0.2-2.rhel9.x86_64.rpm). Doesn't that make it easier?

[Tostino]

My pain was actually caused by the Postgres website download/install page having outdated install instructions for Debian 11... the wiki was correct and someone pointed out the discrepancy. So in the end, I got everything working just fine. Just bit rotted instructions.

[anayrat]

Hello,

I haven't really thought about getting this into core, for a couple reasons.

1. strong pushback to adding more and more stuff to contrib - there's about a zillion other packages that might be just as useful, and we can't really include all of them. Every package means we need to maintain it, etc.

Indeed, that's true.

2. it ties the release cycles - Including it into contrib means we couldn't introduce new features on stable releases, and can't fix bugs between outside a PG minor. Admittedly, there wasn't much development activity on this.

Yes, but we can have both. New features in an extension out of contrib and old stabilized in contrib. But it requires much more work for the maintainer.

These two issues are pretty much why we have extensions - to allow packages developed and released independently. Adding it to contrib would defeat some of this, unfortunately.

Yes, but users are often reluctant to use it if it is not from the core. Lack of trust, fewer tests... (I have the same issue with RUM indexes thought).

If you want to propose / advocate for including it on pgsql-hackers, be my guest.

But I think it's unlikely to be successful in this extension form. Maybe if it was reworked as an uuid-ossp improvement, adding the new UUID versions (https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-04.html#name-introduction-2) which are however still in draft, AFAICS.

Yes, I understand, as there is no standard about sequential-uuids, this can't be in the core.

I fully understand for Postgres development. We used to have standard things in the core.

But as a user, it is hard to rely on a third party extension when you design your database. I might be afraid this extension no longer be maintained in a few years and be stuck to upgrade Postgres :/

While searching on this subject, I came across this draft about UUIDv6 and 7 https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-04.html#name-sorting and https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/

A customer also told me about ULID that look promising, they are sortable. So we avoid index split and can sort on the uuid column, same as if we sorted on a timestamp column.

Thanks for your answer. I agree with your arguments. Maybe, we should wait for a standardized version of uuid (v6 or v7).

[anayrat]

Another article about uuidv7, ulid and sortability https://blog.daveallie.com/ulid-primary-keys