You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In pgrx 0.11, if someone passes a regclass (which is an OID... so, a u32, really) to a function, we automatically take a lock on relevant relation and do some things that Postgres hints are maybe not sound because we aren't really checking. This is because we are synthesizing the PgRelation type from that OID.
Previous issue
Is this behavior
sound? are the checks Postgres is referencing actually optional in reality? is it okay if we call SPI and pass essentially-random integers into such functions?
desirable? implicitly taking a lock without the ability to specify a LOCKMODE seems like it could be prone to being very "that's not what I wanted"?
The absence of its ArgAbi impl was reported as a bug in #1769. Omitting it was not intentional, but I attempted to do a cursory review of the implications of taking the type as an argument and found it surprising.
We've determined this is probably okay despite the comment, but that it's not necessarily desirable. We've selected this implicit LOCKMODE argument which may be okay for many uses but is not really a selection we should be making for you, and there are other reasons for wanting a Regclass that don't have to do with "immediately lock it".
The text was updated successfully, but these errors were encountered:
There was an extended conversation which got into the deep philosophy of how pgrx should handle arguments. It is... mostly out of scope for this issue. However, we kind of think the answer is that our current implementation is useful but not necessarily desirable because of its implicitness. There's other reasons to want a regclass (which is basically an OID, as discussed), and the only reason PgRelation is our current translation for it is that previously there was an assumption that you would always want to take a lock on the relation if you had it as an argument.
So we're going to drop support for PgRelation for now. This issue will remain open as we are going to want to add a semi-proper Regclass type.
In pgrx 0.11, if someone passes a
regclass
(which is an OID... so, a u32, really) to a function, we automatically take a lock on relevant relation and do some things that Postgres hints are maybe not sound because we aren't really checking. This is because we are synthesizing thePgRelation
type from that OID.Previous issue
Is this behavior
The absence of its ArgAbi impl was reported as a bug in #1769. Omitting it was not intentional, but I attempted to do a cursory review of the implications of taking the type as an argument and found it surprising.
We've determined this is probably okay despite the comment, but that it's not necessarily desirable. We've selected this implicit LOCKMODE argument which may be okay for many uses but is not really a selection we should be making for you, and there are other reasons for wanting a Regclass that don't have to do with "immediately lock it".
The text was updated successfully, but these errors were encountered: