Re: Cannot find hstore operator

Поиск
Список
Период
Сортировка
От Paul van der Linden
Тема Re: Cannot find hstore operator
Дата
Msg-id CAEC-EqB9Aa0tgitK7xzrbMq=uVc_VE6xGL0reo5j0KbCqOb0=Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cannot find hstore operator  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Cannot find hstore operator
Re: Cannot find hstore operator
Список pgsql-general
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 <tgl@sss.pgh.pa.us> wrote:
Paul van der Linden <paul.doskabouter@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

В списке pgsql-general по дате отправления:

Предыдущее
От: Garfield Lewis
Дата:
Сообщение: Re: [EXT] Re: Can we get the CTID value
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Cannot find hstore operator