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