OUT parameter ordering

[jim-mlodgenski]

There is an issue with OUT parameters being in the front of the argument list. When creating a function like this:

CREATE FUNCTION one_out(OUT o integer, i integer) AS
$$
	Some(100 + i.unwrap())
$$
LANGUAGE plrust;

I get a compilation error:

error[E0425]: cannot find value `i` in this scope

However, if I switch the order of the arguments, it works fine.

CREATE FUNCTION one_out(i integer, OUT o integer) AS
$$
	Some(100 + i.unwrap())
$$
LANGUAGE plrust;

[eeeebbbbrrrr]

Probably the broader issue here is that we don’t have support for OUT parameters at all.

Need to think about what this looks like for pgx before we can bring it forward to pl/rust.

[workingjubilee]

Rust does not have a concept of "out parameters" as-such. Most often, in languages, an out parameter is implemented as a pointer to data that may or may not be initialized and thus may or may not be written into. This is not strictly necessary in Rust as Rust has functions which are allowed multiple return values (as a tuple, fixed-size array, slice, complex struct, or whatever else) so it's not a common pattern. Likewise, so does PostgreSQL, as CREATE FUNCTION can be declared as RETURNS TABLE.

Rust does, however, have &mut T. A problem: &mut T currently asserts read-validity (thus, the data must be initialized to a valid value of T) AND write-validity, thus it reflects what PostgreSQL calls INOUT. And unlike PostgreSQL, Rust has no problem having multiple arguments, with some of them being &mut, and a complex return value, whereas PostgreSQL doesn't permit OUT or INOUT parameters combined with RETURNS TABLE. And needless to say, while Rust does have *mut T, which doesn't require data validity, it's a little harder to assign a value to that safely!

So, my question would be this: what exactly are we trying to achieve with OUT parameters? In Rust, you can in fact do things that look a lot like using "out parameters", but those are purely an optimization, really. I would expect Rust's inherent speed to overwhelm other factors here, so I would expect this to be a question of ergonomics.

[jim-mlodgenski]

An OUT parameter is mostly a legacy syntax from commercial databases as a way to pass back results to the calling application from stored procedures which do not provide function results. There are still many applications using that syntax. Other procedural languages just hijack the return value mechanism and map that to the OUT parameters. If we want PL/Rust to play a part in migrations from commercial databases to PostgreSQL, supporting OUT parameters would be a big help. It allows applications code to remain relatively unchanged for the migration when the code is expecting OUT parameters instead of return values.

[workingjubilee]

If this is purely as a form of syntactic sugar to make it easier to port code, then sure, that can be arranged. It could even be done in a way to make it "look" like a proper "out parameter", especially in PL/Rust, but it would probably, yes, use a normal return.

Regardless of how, it would not be in a form where it is valid for the PL/Rust function to not assign to an out parameter, because supporting that is far more trouble than it's worth.

[workingjubilee]

We discussed this a bit today and we're in agreement that this will probably happen and we will probably make it equivalent to using a mut or &mut parameter (especially for INOUT, as OUT is slightly more confusing in terms of picking semantics for it), it's mostly a matter of "when" and doing some research.