Repository navigation
Support for custom (opaque) type #384
Description
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.
Activity
workingjubilee commentedon Sep 15, 2023
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 commentedon Sep 15, 2023
Kinda my current thought process too. I think there's enough information in the
pg_typecatalog 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 commentedon Sep 15, 2023
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 commentedon Sep 15, 2023
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 commentedon Sep 18, 2023
Im probably lacking some background context, im curious
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