Type Alias pgrx_pg_sys::regproc

source ·

pub type regproc = Oid;

Aliased Type§

struct regproc(/* private fields */);

Implementations§

source §

impl Oid

source

pub const INVALID: Oid = _

source

pub const unsafe fn from_u32_unchecked(id: u32) -> Oid

Generate an Oid from an arbitrary u32.

Safety

This allows you to create an Oid that Postgres won’t recognize and throw it into Postgres. Don’t.

You should know what kind of object the identifier would imply before creating it. Postgres may sometimes call very different internal functions based on an Oid input. The extension programming interface of Postgres can reach deep, calling functions that assume the caller should be trusted like Postgres would trust itself. Because it is. Postgres tables can also change at runtime, so if an Oid is not a BuiltinOid, what Postgres does based on an Oid can change dynamically.

The existence of this unsafe requirement to create arbitrary Oids does not, itself, constitute a promise any Oid from Postgres or PGRX is guaranteed to be valid or sensical. There are many existing problems in the way of this, for example:

Oid includes the guaranteed-wrong values Oid::INVALID
Postgres may return arbitrary-seeming Oids, like BuiltinOid::UNKNOWNOID
an Oid can arrive in Rust from a table a non-superuser can write
PGRX mostly relies on Rust’s type system instead of the dynamic typing of Postgres, thus often deliberately does not bother to remember what OID something had.

So this function is merely a reminder. Even for extensions that work with many Oids, it is not typical to need to create one from an arbitrary u32. Prefer to use a constant, or a BuiltinOid, or to obtain one from querying Postgres, or simply use Oid::INVALID. Marking it as an unsafe fn is an invitation to get an Oid from more trustworthy sources. This includes Oid::INVALID, or BuiltinOid, or by directly calling into Postgres. An unsafe fn is not an officer of the law empowered to indict C programs for felonies, nor cite SQL statements for misdemeanors, nor even truly stop you from foolishness. Even “trustworthy” is meant here in a similar sense to how raw pointers can be “trustworthy”. Often, you should still check if it’s null.

source