Обсуждение: Need some clarification

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 * show additional columns if they are added after 
the view is created. *

Dropping/altering column is not allowed in the above mentioned scenario. 
Only it fails for (select *)
What are the other cases in which it fails?

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.
It is right?*
*

"Dhanaraj M" <Dhanaraj.M@Sun.COM> 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.
> It is right?*
> *

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.

Regards,
Qingqing 

"Qingqing Zhou" <zhouqq@cs.toronto.edu> 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 "sinval" code for tracking
catcache invalidations).  What needs to be done is setting up some
infrastructure for storing plans and recognizing that a particular plan
is invalidated by a particular sinval message.  I think Neil's done some
work on this.
        regards, tom lane