Postgres 18 support

[kenwarner]

Could we get an update for Postgres v18 support?

Additionally, would it be possible to take advantage of the native uuidv7() function now available in v18?

[blitss]

Yes I'll take care of postgres@18 support this week

Typeid/uuid generation happens inside the library, so there's no point to use postgres uuid tools

[kenwarner]

thanks blitss appreciate your work on this.

would there be any benefit to doing a migration something like this

CREATE OR REPLACE FUNCTION typeid_uuid_generate_v7()
RETURNS uuid
LANGUAGE sql
AS $$ SELECT uuidv7() $$;

I know the rust Uuid::now_v7() works fine and i'm sure there's little to no computational overhead to creating the uuid through the extension rather than postgres native c, but just wanted to put it out there i guess. thanks again :)

[blitss]

would there be any benefit to doing a migration something like this

@kenwarner sorry for the late reply, typeid_uuid_generate_v7 is merely a way to generate uuid same way library does

fn typeid_uuid_generate_v7() -> pgrx::Uuid {
    pgrx::Uuid::from_bytes(*Uuid::now_v7().as_bytes())
}

It's not used internally by the extension at all, it's just a public function for people who want a SQL-callable helper that mirrors the Rust implementation.

Right now there’s no strong benefit to replacing the Rust generation with uuidv7(). In both cases we still end up with 16 bytes of UUID that we feed into the TypeID logic; whether those bytes come from Rust or Postgres doesn’t materially change performance or capabilities.

If you want native Postgres generator I suppose you could use something like uuid_to_typeid('user', uuidv7()) but there's no real benefit to it