On Fri, Sep 14, 2012 at 12:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Hitoshi Harada <umi.tan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
