Re: 'prepare' is not quite schema-safe
От | Tom Lane |
---|---|
Тема | Re: 'prepare' is not quite schema-safe |
Дата | |
Msg-id | 10989.1115012673@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 'prepare' is not quite schema-safe (Vlad <marchenko@gmail.com>) |
Ответы |
Re: 'prepare' is not quite schema-safe
Re: [Dbdpg-general] Re: 'prepare' is not quite schema-safe |
Список | pgsql-general |
Vlad <marchenko@gmail.com> writes: > so is it possible that a successfully prepared (and possibly a couple > of times already executed) query will be invalidated by postgresql > for some reason (like lack of memory for processing/caching other > queries)? Assuming that no database structure changes has been > performed. Well, that assumption is wrong to start with: what if the query plan uses an index that someone else has chosen to drop? Or the plan depends on an inlined copy of a SQL function that someone has since changed? Or the plan was chosen on the basis of particular settings of planner parameters like random_page_cost, but the user has changed these via SET? (The last is a pretty close analogy to changing search_path, I think.) I am not claiming that the backend handles all these cases nicely today: it certainly doesn't. But we understand in principle how to fix these problems by invalidating plans inside the backend. I don't see how the DBD::Pg driver can hope to deal with any of these situations :-( regards, tom lane
В списке pgsql-general по дате отправления: