I wrote: > [ discussion about ways to let extension C code find out object OIDs ]
I wanted to close out this thread, for the time being, by saying that I'm not expecting to get anything done about it for v12. It seems pretty late in the dev cycle to be proposing any major new user-visible functionality, and even without that consideration, I have too many other things on my plate. There are ways that an extension can implement SupportRequestIndexCondition without knowing hard-wired OIDs for its objects: 1. The first problem is to determine whether the index column you've been called for has the opfamily you want to work with. Our core-code examples mostly check req->opfamily against a hard-wired OID constant, which doesn't work for an extension-defined opfamily. I think best practice here will probably be to look up the opfamily's catalog entry via the OPFAMILYOID syscache and see if its name is what you expect (checking only the name, not the schema, since the latter might be variable). While a false match is theoretically possible it seems unlikely, and there's not a security risk since we only allow superusers to create opfamilies. Another idea is to check req->index->relam to see if the index type is what you expect, and just assume that your datatype has only one opfamily per index type. This is mainly attractive if the index type is a built-in one with a known OID --- if the index AM is also extension-defined, then you're still stuck needing to look up and check its name. 2. Then, you need to be able to identify operator OIDs so that you can build indexqual OpExprs. The operators you care about for this have to be members of the opfamily, so you can look up their OIDs pretty easily using get_opfamily_member ... assuming you know the OIDs of their input datatypes (see below). like_support.c has examples of this. 3. You might need to determine datatype OIDs, for the above purpose and so that you can build comparison constants to pass to the operators. This is pretty easy if the comparison value is of the same type as one of the inputs to your function or operator being optimized: just apply exprType() to that input expression. However there are cases where this isn't true; for instance, PostGIS sometimes wants to optimize a function with more than 2 inputs by converting "func(indexcol, something, something)" to "indexcol indexable-operator row(something, something)::compositetype". The OID of the custom composite type isn't readily available. In such cases you might have no really better answer than to look up the type by name. This can probably be done safely by assuming that it's in the same schema as your target function, which you can look up since you have the function's OID. Using the type OID successfully in a later get_opfamily_member lookup would provide additional confidence that you have the right type. In all of these cases, you could probably get away with caching the results of successful lookups in static variables, so that you don't need to do them more than once per session. This is clearly an area that's ripe for improvement by providing better infrastructure, but I think we can tolerate this state of affairs for the time being. regards, tom lane