| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | Peter van Hardenberg <pvh(at)pvh(dot)ca>, Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, "pgsql-hackers\(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Prepared statements fail after schema changes with surprising error |
| Date: | 2013-01-22 18:22:01 |
| Message-ID: | 23687.1358878921@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> DROP SCHEMA public;
>>> CREATE SCHEMA public;
>> changes the OID of schema public, whereas the search_path that's cached
>> for the cached plan is cached in terms of OIDs. So while there is a
>> table named public.z1 at the end of the sequence, it's not in any schema
>> found in the cached search path.
> The DROP SCHEMA should invalidate the cached plan, certainly?
It does not; see my reply to Robert.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2013-01-22 18:35:52 | Re: Prepared statements fail after schema changes with surprising error |
| Previous Message | Tom Lane | 2013-01-22 17:44:19 | Re: Prepared statements fail after schema changes with surprising error |