Comments (5)
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.
from plrust.
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.
from plrust.
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.
from plrust.
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.
from plrust.
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.
from plrust.
Related Issues (20)
- Plrustc will not compile on alpine/postgres. HOT 3
- Compiling multiple functions together HOT 7
- fix `plrust/build` to dynamically determine pgrx version HOT 1
- Some examples appear to always ERROR HOT 4
- Support for custom (opaque) type HOT 5
- plrustc does not seem to catch `include!` macro properly HOT 3
- env/option_env failing to be linted by plrustc HOT 7
- Accessing JsonbContainer HOT 12
- UDF load time is high when compared to PL/PGSQL HOT 2
- How to return an array of any dimenion from pl/rust function.
- Enhancement to prevent cargo from recompiling allowlisted dependencies. HOT 7
- plrust installation fails when postgres 15 compiled with gprof profiler HOT 2
- Publish to https://database.dev/ HOT 9
- enumerated type as function arg? HOT 7
- JSonb extract slower in Pl/Rust than in Pl/PgSql HOT 3
- Postgres Triggers, achieve different behaviour on INSERT, UPDATE, etc.
- Problem with clap v4.5.4 HOT 5
- seg faults when working with composite types HOT 2
- Support for Postgres 17 HOT 3
- Statement timeout during `cargo build` leads to crash HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from plrust.