Re: Re: Querying foreign table with SP-GiST index results in “ERROR: cache lookup failed for type 0”
От | Tom Lane |
---|---|
Тема | Re: Re: Querying foreign table with SP-GiST index results in “ERROR: cache lookup failed for type 0” |
Дата | |
Msg-id | 18552.1561592383@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Querying foreign table with SP-GiST index results in “ERROR: cache lookup failed for type 0” (Paul Ramsey <pramsey@cleverelephant.ca>) |
Ответы |
Re: Re: Querying foreign table with SP-GiST index results in “ERROR: cache lookup failed for type 0”
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: