Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

Robert Haas writes: > On Fri, Aug 12, 2016 at 3:22 PM, Tom Lane wrote: >> Hm. I think that sounds a lot easier than it actually is. As an example, >> this would mean that we'd want such a search_path setting to apply during >> parse analysis of a

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On Fri, Aug 12, 2016 at 3:22 PM, Tom Lane wrote: > Robert Haas writes: >> Let's introduce a new variant of SET that only affects the lexical >> scope of the function to which it is attached, and then do what you >> said. That would be full of win,

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

Robert Haas writes: > Let's introduce a new variant of SET that only affects the lexical > scope of the function to which it is attached, and then do what you > said. That would be full of win, because actually I think in nearly > every case that's the behavior people

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On Thu, Mar 10, 2016 at 11:48 AM, Tom Lane wrote: > Robert Haas writes: >> Hmm. The meaning of funcs.inline depends on the search_path, not just >> during dump restoration but all the time. So anything uses it under a >> different search_path setting

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

> Michael Banck writes: >> As I've been bitten by this problem recently, I thought I'd take a >> look at editing the PostGIS extension SQL file to this end, but >> contrary to the above, the @extschema@ feature only applies to >> non-relocatable extensions, from

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

Michael Banck writes: > As I've been bitten by this problem recently, I thought I'd take a look > at editing the PostGIS extension SQL file to this end, but contrary to > the above, the @extschema@ feature only applies to non-relocatable > extensions, from

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote: > If you're worried about preserving relocatability of an extension > containing such functions, the @extschema@ feature might help. As I've been bitten by this problem recently, I thought I'd take a look at editing the PostGIS extension

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

* Bruce Momjian (br...@momjian.us) wrote: > On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote: > > Robert Haas writes: > > > Hmm. The meaning of funcs.inline depends on the search_path, not just > > > during dump restoration but all the time. So anything uses it

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote: > Robert Haas writes: > > Hmm. The meaning of funcs.inline depends on the search_path, not just > > during dump restoration but all the time. So anything uses it under a > > different search_path setting than the

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining? - and backup / restore issue

>> On 3/10/16 3:29 PM, Regina Obe wrote: >> Take for example, I have tiger geocoder which relies on fuzzystrmatch. I >> have no idea where someone installs fuzzystrmatch so I can't schema qualify >> those calls. I use that dependent function to use to build an index on >> tables. > This is

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining? - and backup / restore issue

On 3/10/16 3:29 PM, Regina Obe wrote: Take for example, I have tiger geocoder which relies on fuzzystrmatch. I have no idea where someone installs fuzzystrmatch so I can't schema qualify those calls. I use that dependent function to use to build an index on tables. This is something I've

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining? - and backup / restore issue

> Hmm. The meaning of funcs.inline depends on the search_path, not just during > dump restoration but all the time. So anything uses it under a different > search_path setting than the normal one will have this kind of problem; not > just > dump/restore. > I don't have a very good idea

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

Robert Haas writes: > Hmm. The meaning of funcs.inline depends on the search_path, not just > during dump restoration but all the time. So anything uses it under a > different search_path setting than the normal one will have this kind > of problem; not just dump/restore.

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On Thu, Mar 10, 2016 at 3:21 AM, Regina Obe wrote: > When you back up the database, it would create a backup with this line: > > SET search_path = public, pg_catalog; > --your create materialized view here > > When you restore even if your database has search_paths set, your >

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

-Original Message- > From: Andreas Karlsson [mailto:andr...@proxel.se] > Sent: Tuesday, March 08, 2016 10:43 PM > To: Regina Obe <l...@pcorp.us>; 'Robert Haas' <robertmh...@gmail.com> > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Is there a way

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On 03/08/2016 01:24 AM, Regina Obe wrote: On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe > wrote: I think the answer to this question is NO, but thought I'd ask. A lot of folks in PostGIS land are suffering from restore issues, materialized view issues etc. because we have functions

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

>> On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe > wrote: >> I think the answer to this question is NO, but thought I'd ask. >> >> A lot of folks in PostGIS land are suffering from restore issues, >> materialized view issues etc. because we have functions such as >> >> ST_Intersects

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe wrote: > I think the answer to this question is NO, but thought I'd ask. > > A lot of folks in PostGIS land are suffering from restore issues, > materialized view issues etc. because we have functions such as > > ST_Intersects > > Which