Re: Prepared statements fail after schema changes with surprising error

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 23, 2013 at 11:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Your point that the locking code doesn't quite cope with newly-masked
>> objects makes me feel that we could get away with not solving the case
>> for plan caching either. Or at least that we could put off the problem
>> till another day. If we are willing to just change plancache's handling
>> of search_path, that's a small patch that I think is easily doable for
>> 9.3. If we insist on installing schema-level invalidation logic, it's
>> not happening before 9.4.

> I agree with that analysis. FWIW, I am pretty confident that the
> narrower fix will make quite a few people significantly happier than
> they are today, so if you're willing to take that on, +1 from me. I
> believe the search-path-interpolation problem is a sufficiently
> uncommon case that, in practice, it rarely comes up. That's not to
> say that we shouldn't ever fix it, but I think the simpler fix will be
> a 90% solution and people will be happy to have made that much
> progress this cycle.

Here's a draft patch for that. I've not looked yet to see if there's
any documentation that ought to be touched.

With this patch, PushOverrideSearchPath/PopOverrideSearchPath are used
in only one place: CreateSchemaCommand. And that's a very simple,
stylized usage: temporarily push the new schema onto the front of the
path. It's tempting to think about replacing that klugy code with some
simpler mechanism. But that sort of cleanup should probably be a
separate patch.

regards, tom lane