Dhanaraj M [EMAIL PROTECTED] wrote
2. *Invalidate prepared queries, like INSERT, when the table
definition is altered
*Invalidation means recompilation or deletion of the prepared stmt
here.*
*Both the items look similar. i.e) needs recompilation of the query
after altering the table.
Qingqing Zhou [EMAIL PROTECTED] writes:
Yes, IMHO the basic idea is like that - the difficulty is that we are
lack of efficient object tracking mechanism, so that when an underlying
object is changed, all the prepared plans should be invalidated.
The basic signaling mechanism does exist (the
I could see the following in TODO list
but I am not clear what is expected out of this.
Can anyone explain this?
1. *Allow VIEW/RULE recompilation when the underlying tables change *
*Another issue is whether underlying table changes should be
reflected in the view,
e.g. should SELECT *
