Thanks for the clarification, but giving up performance is a no-go for us. Also I have my concerns about shemaqualifying each and every use of the -> operator, there are really a lot of them in my functions and it would severely impact readability. Are these the only 2 solutions possible?
Paul On Thu, Jan 20, 2022 at 3:05 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Paul van der Linden <paul.doskabou...@gmail.com> writes: > > during maintenance I saw a lot of lines in my postgreslog saying: > > CONTEXT: SQL function "line_function" during inlining > > automatic analyze of table "osm.planet_osm_line" > > ERROR: operator does not exist: public.hstore -> unknown at character 45 > > It sounds like line_function is careless about its search path > assumptions. auto-analyze will run index expressions with the > search_path set to empty (i.e., only pg_catalog is accessible) > and hstore isn't normally installed in pg_catalog. > > The easy fix would be to attach "SET search_path = public" > to that function, but I believe that destroys the ability to > inline it, which might be a performance problem for you. > Alternatively you could schema-qualify the operator name, > that is "foo OPERATOR(public.->) bar". > > regards, tom lane >
