"Records like structs"

[workingjubilee]

If I'm going to suffer through the implementation of so many accursed macros, then implementing returning a composite type should be as simple as

#[pg_extern]
fn returns_my_composite_type() -> RetType {
    todo!()
}

#[derive(PgRecord)]
struct RetType {
   field_0: i32,
   field_1: String,
}

This much pain and effort to create a sound library is only worth it if the results are
PURE
MAGIC.

Allowing grodier, "lower-level" handling also is fine, too, but that should be the default.

[workingjubilee]

For cases where the fields use characters that aren't acceptable in Rust identifiers, or the type has such a name, I think the style where you offer #[pgrx(rename = "name")] is more "to the point" than our current implementation.

[workingjubilee]

The main problem with this is that composite types can be dynamically redefined at runtime, adding or subtracting fields. However, that doesn't particularly seem like a meaningful concern for composite types that are defined by the extension itself, as then the logical expectation is that if you redefine something in the extension, you rebuild the extension. Trying to have an implementation that unites both the "external" composite type and the "internal" composite type cases seamlessly, when those are significantly different to actually interact with, is slightly problematic.

[workingjubilee]

( obviously we should panic if we can't satisfy the deserialization request anymore. )

[workingjubilee]

So, unless something changed in Postgres 16 or Postgres 17, composite types can be changed at runtime but it's a pain in the ass to do because Postgres will issue an error if the composite type is actually used as a column anywhere (since that requires rebuilding the column, basically).