Document `Result<T, Err>` usage with `#[pg_extern]`, or panic as a preferred method

[nyurik]

In Rust, panics tend to be 2nd class as they may result in various lock poisoning, slower perf, etc. Yet, it seems #[pg_extern] expects most functions to be returning the actual value rather than a Result<T, E>. I tried to look for any documentation, and saw a few examples like this one where the error type is Box<dyn std::error::Error + Send + Sync + 'static>. What is best approach to errors, and where can this be documented?

#[pg_extern]
fn result_table() -> Result<
    Option<::pgrx::iter::TableIterator<'static, (name!(a, Option<i32>), name!(b, Option<i32>))>>,
    Box<dyn std::error::Error + Send + Sync + 'static>,
> {
    Ok(Some(TableIterator::new(vec![(Some(1), Some(2))])))
}

[workingjubilee]

In Rust, panics tend to be 2nd class as they may result in various lock poisoning, slower perf, etc.

Postgres throws its own hand-rolled "exceptions" so all pgrx functions are prone to panic (as we promote them to panics). Initially pgrx leaned heavily into a design that reflects that of Postgres, and only over time has it drifted towards a design that balances that with Rust's inclinations, partly due to requiring more... interesting... implementations to abstract over certain things.

What is best approach to errors,

Honestly, I dunno!

and where can this be documented?

We do have ./docs

[nyurik]

Thx, i guess it will be a discovery process :)

Would it make sense in the future to gravitate towards standard Rust Result errors that can be simply .to_string() when passing to Postgres? This way all Rust code will become more stable without the accidental .unwrap() and such, and only at the FFI convert it to a Postgres exception? I suspect it would also prevent accidental lock poisoning if multithreading is used.

The /docs looks like an mdbook, but there are no links in the README to it. Is it being published anywhere?

[workingjubilee]

It's not currently being published no, I have a vague intention of setting that up.

[mvisani]

@workingjubilee Any updates on preferred methods on returning Results ? Is there any reference regarding this ?