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

2016-08-12 Thread Tom Lane
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 function's body, but not during planning, becaus

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

2016-08-12 Thread Robert Haas
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, because actually I think in nearly >> every case

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

2016-08-12 Thread Tom Lane
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 actually want. Hm. I think

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

2016-08-12 Thread Robert Haas
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 than the normal one will have this kind >> o

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

2016-08-10 Thread Regina Obe
> 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 src/backend/commands/extension.

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

2016-08-10 Thread Tom Lane
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 src/backend/commands/extension.c: > *

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

2016-08-10 Thread Michael Banck
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 SQ

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

2016-04-25 Thread Stephen Frost
* 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 under a > > > different se

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

2016-04-25 Thread Bruce Momjian
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 normal one will have this

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

2016-03-12 Thread Regina Obe
>> 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 s

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

2016-03-11 Thread Jim Nasby
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 th

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

2016-03-10 Thread Regina Obe
> 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 wha

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

2016-03-10 Thread Tom Lane
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. Yeah, I see no reason

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

2016-03-10 Thread Robert Haas
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 > materialized view w

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

2016-03-10 Thread Regina Obe
-Original Message- > From: Andreas Karlsson [mailto:andr...@proxel.se] > Sent: Tuesday, March 08, 2016 10:43 PM > To: Regina Obe ; 'Robert Haas' > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Is there a way around function search_path killing

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

2016-03-08 Thread Andreas Karlsson
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 such as ST_Inte

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

2016-03-07 Thread Regina Obe
>> 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 does

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

2016-03-07 Thread Robert Haas
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 does _ST_Intersect

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

2016-03-04 Thread Regina Obe
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 does _ST_Intersects AND && Since _ST_Intersects is not schema qualified, durin