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
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
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
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
> 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.
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:
> *
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
* 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
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
>> 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
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
> 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
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
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
-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
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
>> 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
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
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
19 matches
Mail list logo
