From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Paul van der Linden <paul(dot)doskabouter(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Cannot find hstore operator |
Date: | 2022-01-20 14:05:23 |
Message-ID: | 856144.1642687523@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Paul van der Linden <paul(dot)doskabouter(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ekaterina Amez | 2022-01-20 14:31:06 | Query much slower from php than psql or dbeaver |
Previous Message | David G. Johnston | 2022-01-20 12:58:24 | Re: Multiple SELECT statements Using One WITH statement |