Etsuro Fujita <
etsuro.fujita@gmail.com> writes:
I found that this error is thrown by index_can_return()
(spgcanreturn()) called from get_relation_info() for the SP-GiST index
on the locations table.
PGDLLEXPORT Datum gserialized_spgist_config_2d(PG_FUNCTION_ARGS)
{
spgConfigOut *cfg = (spgConfigOut *)PG_GETARG_POINTER(1);
--> Oid boxoid = TypenameGetTypid("box2df");
cfg->prefixType = boxoid;
cfg->labelType = VOIDOID; /* We don't need node labels. */
cfg->leafType = boxoid;
cfg->canReturnData = false;
cfg->longValuesOK = false;
PG_RETURN_VOID();
}
I'm a newbie to PostGIS, so maybe I'm missing something, but isn't it
a bit fragile to use TypenameGetTypid() here?
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.
This is a Postgis bug. It's probably not quite trivial to solve,
since this code can't know what schema the type is installed in
at runtime. This seems related to the discussions we had awhile
ago about how planner support functions can find out the OIDs of
extension objects reliably. I'm not sure where Paul is on that...
Well, I seemed able to skate around the supportfn problem without having to lookup types.
TypenameGetTypid() does show up in a number of places in the PostGIS code base, so this is a little concerning.
The SPGist code definitely has it, probably calls to ST_EstimatedExtent, ST_AsMVT and ST_AsGeoBuf would also fail in an FDW context, if the problem manifests the same everywhere.
There’s some code in other places that attempts to cache the relevant Oids for geometry and geography on first function call, but that wouldn’t really solve the problem.
We had a similar problem, if I recall correctly, doing lookups of spatial reference information, for similar reasons: calling over FDW the search_path was so limited the internal lookup functions couldn’t find the spatial_ref_sys table. I just looked up the work-around, and it looks like we infer that the table we’re looking for (part of PostGIS) resides in the same schema as the calling function (part of PostGIS), and then cache that schema name for future use.
I’m not sure if this same ugly trick would work for the spgist problem, but maybe so?
P