"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 exis
"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
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 *
