From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Plan cache and name space behavior in 9.2 |
Date: | 2012-09-14 19:55:13 |
Message-ID: | 20271.1347652513@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)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. (The planner is trying to estimate the value
of the expression 'tname::regclass::oid', which is why this happens
with the old search_path setting --- it wouldn't fail at runtime.)
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.
There's been periodic discussion of how the plan cache ought to interact
with search_path anyway --- maybe it shouldn't try to restore the
previous search_path setting but rather view current search_path as part
of the cache lookup key. I'd be hesitant to back-patch such a behavior
change, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hitoshi Harada | 2012-09-14 20:18:05 | Re: Plan cache and name space behavior in 9.2 |
Previous Message | Alvaro Herrera | 2012-09-14 19:50:37 | Re: embedded list v2 |