On Sat, 2005-03-19 at 01:10 -0500, Jaime Casanova wrote:
> On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Jaime Casanova <systemguards@gmail.com> writes:
> > > ... but if we do INSERT INTO vfoo(col2) values ('some_string) the
> > rewriter
> > > cann resolv the value for col1. the reason is that views does not
> > > inherit the defaults of the parent table. That is the reason you add
> > > the ALTER TABLE ALTER COLUMN ADD/DROP DEFAULT for views.
> >
> > > Ok, this is a problem for us, so we want to improve the rewriter to
> > > see the default in the base table an add it as appropiate.
> >
> > Why do you not define the problem as "when we decide a view is
> > updateable and create the needed rules for it, also create default
> > values for it by copying up from the base tables"?
> >
> Well, that was our first thought. but what if the default value is
> changed in the base table? then we have a problem, can we found in
> what views we have to alter the default value in order to keep
> consistency.
I can see that I might want the view to have a different default value
from that of the underlying table. I can see a reason to have multiple
updateable views on the same table, all with different columns, column
defaults and row selection clauses. (Multiple classes all held within
the same physical table, for example).
I'd suggest - if the default value for a column on a view IS NOT set,
then use the default value from the underlying table. If it IS set, then
it should stay set, even if the underlying table changes. That might
need some dependency logic in there...
Best Regards, Simon Riggs
