Support for custom (opaque) type

[anth0nyleung]

PL/Rust does not support non-builtin custom types.

it would be a nice feature if pl/rust function can accept or return them.

postgres=# create extension plrust ;
CREATE EXTENSION
postgres=# create extension citext ;
CREATE EXTENSION
postgres=# create function foo (ct citext) returns void language plrust as $$ Ok(Some(())) $$;
ERROR:
   0: Oid `oid=#16586` was not mappable to a Rust type

Location:
   plrust/src/user_crate/crate_variant.rs:99

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

[workingjubilee]

Perhaps we should try to make it easy to write crates that extend pgrx with other extension's types like that, or provide a way of automatically binding the custom types. In this specific case, we can try to make it easier for binary-compatible types with existing known types, though.

[eeeebbbbrrrr]

or provide a way of automatically binding the custom types.

Kinda my current thought process too. I think there's enough information in the pg_type catalog to make sure we don't mis-handle the backing bytes. But there's a gap from that to "actually usable in a Rust function" that I'm unsure about.

[workingjubilee]

or provide a way of automatically binding the custom types.

Kinda my current thought process too. I think there's enough information in the pg_type catalog to make sure we don't mis-handle the backing bytes. But there's a gap from that to "actually usable in a Rust function" that I'm unsure about.

Well, there are transformation functions that Postgres knows about, and presumably the one of "citext -> text" is basically a no-op, so perhaps we can ask Postgres to do it for us, invoking the transformation function to get a type PL/Rust already knows about? And then we push that into the usual extern "C" shim. We'd offer some kind of syntax for "do this, please".

It is possible this violates the intention of @anth0nyleung though, by exposing a repr of the type.

[eeeebbbbrrrr]

Hmm. That’s a good thought, actually. Either the xform functions or perhaps through casts (maybe that’s a problem for another day tho).

I think where I’m still a little unsure is how the user tells us which rust type they want the argument to be. For pgrx that’s probably doable with generics at compile time. For plrust I am not sure.

We’d almost need some kind of plrust function where the args are passed as a struct and which has a get_arg() function. And that leaves me wondering how the user tells us to use that function style.

[anth0nyleung]

It is possible this violates the intention of @anth0nyleung though, by exposing a repr of the type.

Im probably lacking some background context, im curious

1. Why would the repr of the type be exposed?
2. In what fashion would the repr of the type be exposed?
3. What would be the impact / implication of exposing it?

citext is just an example, i think generally we want to enable the support to any type. Im guessing there will be limitation and im interested to understand them. Part of this feature / enhancement request is also because we want to leverage and extend this to the custom type created from the apis we are providing in pg_tle https://github.com/aws/pg_tle/blob/main/docs/09_datatypes.md