Add commutator #16
Add commutator #16
Conversation
pksunkara
force-pushed
the
fixes-13
branch
3 times, most recently
from
8c85a66 to
edd3c35
Compare
Derived from pksunkara/pgx_ulid#16 The test guarantees hash joins and commutative joins work, but by default yield an error something like: could not find commutator for operator 140551 postgres location: clauses.c rust location: SQL statement "CREATE TABLE hexintext ( ...and so on. By indicating that these operators commute with each other we can allow Postgres to use this while implementing joins.
|
If pgcentralfoundation/pgrx#1261 lands in some form, you can land this with minimal changes. Until then, you could, I guess, define the pg_extern functions and annotate them with pg_operator macros by hand? ...yeah that's not great. |
Thanks.
Could you please point me to an example? I had trouble getting this working. |
This fixes pksunkara/pgx_ulid#16 without requiring additional work on the part of the programmer. However, there is a design decision here: do we require explicit annotation before assuming commutative equality or not? Here I chose to demand that the equality implementation adheres to Rust's requirements for "total" equality. However, as the SQL we emit is used deep inside Postgres for various forms of algebraic reasoning, including, as I understand it, index maintenance, I can't promise that we don't wind up running afoul of Postgres using this data in a way that will incur UB if the implementation is actively malicious, as can be done with implementations of the following kind: ```rust impl PartialEq for AlwaysRandom { fn eq(&self, other: &Self) -> bool { rand::random() } } impl Eq for AlwaysRandom { } ``` Of course, this also violates PARALLEL SAFE and IMMUTABLE. This problem also was always true, as we emitted NEGATOR clauses, which means even this was probably already broken: ```rust impl PartialEq for AlwaysWrong { fn eq(&self, other: &Self) -> bool { false } } impl Eq for AlwaysWrong {} ``` This is less likely to cause issues in more realistic code samples.
|
I landed it, so pgrx 0.10.0 (or 0.10.0-beta.4, or whatever) will fix your code. |
|
@workingjubilee Thank you for the help. Any timeline you guys are thinking for 0.10.0? |
|
To actually answer this question:
It would basically be like writing the fully-expanded, specific-type-instantiated version of this macro's inner contents: But one might also have to correctly invoke the relevant parts of |
No description provided.