Re: Plan cache and name space behavior in 9.2 - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Plan cache and name space behavior in 9.2
Date
Msg-id CAP7QgmnKMw0XK_wRynA1i_bi++S6hqGKH6od6NbAMHy-DFyU7Q@mail.gmail.com
Whole thread Raw
In response to Re: Plan cache and name space behavior in 9.2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Sep 14, 2012 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hitoshi Harada <umi.tanuki@gmail.com> writes:
>> I expected success in tname::regclass in the function chck(), but it
>> actually fails for your first run in the session.
>
> Really?  Not for me.
>
> In the example as given, I see success for "call 1" and then an error at
> "call 2", which is occurring because we're trying to replan the query
> with the original search_path, which doesn't include the temp schema
> since it didn't exist yet.

I'm saying the same thing actually.  I see success for call 1 and
error at call 2, which was not observed in 9.1 and older.

> A replan would have failed in previous versions too, but that's much
> less likely in previous versions since you'd need to see a relcache
> invalidation on one of the referenced tables to make one happen.

I don't think so.  I tried it in 9.1 and succeeded.  I found this
during the test of an external module that has been running back to
8.4.  So I wonder if we could say this is a behavior change or a bug.

And I agree the replan failure would be sane if the function was
marked as immutable or stable, but all the functions I defined in the
example is volatile.  I'm not sure how others feel, but at least it's
surprising to me that the call 2 keeps the state of call 1 though it
is a volatile function.  I have not been tracking the periodic
discussion of plan cache vs search_path, but what is the beneficial
use case of the new behavior?

Thanks,
-- 
Hitoshi Harada



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Plan cache and name space behavior in 9.2
Next
From: Tom Lane
Date:
Subject: Re: embedded list v2