Re: Cannot find hstore operator

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: Ganesh Korde <ganeshakorde(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul van der Linden <paul(dot)doskabouter(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Cannot find hstore operator
Date: 2022-01-24 10:40:30
Message-ID: CAFCRh-_FRCoarb++pwspbMO9dTh0mCcMorrCGoDivTSpHPCrig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jan 24, 2022 at 11:19 AM Ganesh Korde <ganeshakorde(at)gmail(dot)com> wrote:
> On Mon, 24 Jan 2022, 3:22 pm Dominique Devienne, <ddevienne(at)gmail(dot)com> wrote:
>> Is there any way to achieve that, beside our current `SET search_path` workaround?

> This might help.
> Alter user <user name> SET search_path TO myschema,public;
> No need to set search_path every time.

Hi. Not really, no, I'm afraid.

I'm in charge and control the app's schemas, not the LOGIN USERs using
those schemas.
I.e. my triggers shouldn't have to rely on the session's search_path
at all, and nor how that search_path is set.
Also, the schema(s) to access are dynamic, and some clients don't set
a search_path at all.
My triggers shouldn't stop working when there's no search_path (i.e.
only pg_catalog and pg_temp are implicitly resolved).

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Umair Shahid 2022-01-24 12:32:55 Proposed German Translation of Code of Conduct Policy
Previous Message Ganesh Korde 2022-01-24 10:19:32 Re: Cannot find hstore operator