Paul Ramsey <pramsey@cleverelephant.ca> writes:
>> On Jun 26, 2019, at 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> More than a bit :-(. That's guaranteed to fail if type box2df isn't
>> in the search path, which it likely won't be during a remote query,
>> since postgres_fdw locks down the search path to just pg_catalog.
> We had a similar problem, if I recall correctly, doing lookups of spatial reference information, for similar reasons:
callingover FDW the search_path was so limited the internal lookup functions couldn’t find the spatial_ref_sys table. I
justlooked up the work-around, and it looks like we infer that the table we’re looking for (part of PostGIS) resides in
thesame schema as the calling function (part of PostGIS), and then cache that schema name for future use.
Yeah. The variant I was thinking about was to look up the namespace
of the geometry type (which in this example you could get from attType
of the spgConfigIn parameter struct) and assume that box2df is in that
schema. But working from the function's own schema might be better
because you could do the same thing in all these places, rather than
needing to find an associated object in some call-site-specific way.
regards, tom lane