Re: Prepared statements fail after schema changes with surprising error
От | Robert Haas |
---|---|
Тема | Re: Prepared statements fail after schema changes with surprising error |
Дата | |
Msg-id | CA+TgmobRs3kYSr8vpoQyjK_LeO2z58mFtaMDGZcBJ_5bs10R3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Prepared statements fail after schema changes with surprising error (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Prepared statements fail after schema changes with surprising error
|
Список | pgsql-hackers |
On Wed, Jan 23, 2013 at 11:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Yeah, that is probably the major hazard IMO too. The designs sketched > in this thread would be sufficient to ensure that DDL in one session's > temp schema wouldn't have to invalidate plans in other sessions --- but > is that good enough? > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: