On Mon, Jan 24, 2022 at 9:25 AM Dominique Devienne
wrote:
> On Mon, Jan 24, 2022 at 3:48 PM David G. Johnston
> wrote:
> > On Monday, January 24, 2022, Dominique Devienne
> wrote:
> >>
> >> After re-reading
> >> https://www.postgresql.org/docs/14/sql-createfunction.html in light of
> >> Tom's a
On 1/24/22 08:27, Dominique Devienne wrote:
On Mon, Jan 24, 2022 at 3:48 PM David G. Johnston
wrote:
On Monday, January 24, 2022, Dominique Devienne wrote:
After re-reading
https://www.postgresql.org/docs/14/sql-createfunction.html in light of
Tom's answer,
does that mean that our `SET searc
On Mon, Jan 24, 2022 at 3:48 PM David G. Johnston
wrote:
> On Monday, January 24, 2022, Dominique Devienne wrote:
>>
>> After re-reading
>> https://www.postgresql.org/docs/14/sql-createfunction.html in light of
>> Tom's answer,
>> does that mean that our `SET search_path TO {0}, 'pg_temp'`
>> wor
On Monday, January 24, 2022, Dominique Devienne wrote:
>
> After re-reading
> https://www.postgresql.org/docs/14/sql-createfunction.html in light of
> Tom's answer,
> does that mean that our `SET search_path TO {0}, 'pg_temp'`
> workaround, in the trigger below,
> to not depend on the search_path
On Mon, Jan 24, 2022 at 11:19 AM Ganesh Korde wrote:
> On Mon, 24 Jan 2022, 3:22 pm Dominique Devienne, wrote:
>> Is there any way to achieve that, beside our current `SET search_path`
>> workaround?
> This might help.
> Alter user SET search_path TO myschema,public;
> No need to set search_pa
On Mon, 24 Jan 2022, 3:22 pm Dominique Devienne,
wrote:
> Hi. In
> https://www.mail-archive.com/pgsql-general@lists.postgresql.org/msg29321.html
> I asked:
>
> > On Tue, Jan 11, 2022 at 5:30 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> > > On Tuesday, January 11, 2022, Dominique
Hi. In
https://www.mail-archive.com/pgsql-general@lists.postgresql.org/msg29321.html
I asked:
> On Tue, Jan 11, 2022 at 5:30 PM David G. Johnston
> wrote:
> > On Tuesday, January 11, 2022, Dominique Devienne >
> > wrote:
> >> This means the template-schema name is part of the DDL for the schem
Thanks, works perfectly!
On Sun, Jan 23, 2022 at 4:22 PM Tom Lane wrote:
> Paul van der Linden writes:
> > 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
Paul van der Linden writes:
> 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 t
On Sun, Jan 23, 2022 at 7:54 AM Paul van der Linden <
paul.doskabou...@gmail.com> wrote:
> 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 func
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
O
Paul van der Linden 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
Hi,
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
HINT: No operator matches the given name
13 matches
Mail list logo
