From: | Paul van der Linden <paul(dot)doskabouter(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Cannot find hstore operator |
Date: | 2022-01-23 14:54:34 |
Message-ID: | CAEC-EqB9Aa0tgitK7xzrbMq=uVc_VE6xGL0reo5j0KbCqOb0=Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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 | David G. Johnston | 2022-01-23 15:20:55 | Re: Cannot find hstore operator |
Previous Message | Garfield Lewis | 2022-01-22 14:53:23 | Re: [EXT] Re: Can we get the CTID value |