On Sat, 19 Mar 2005 11:42:18 +0000, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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...
>
And here is were we thought we have to improve the rewriter, if the
rewriter find a default value for a view it will use it if not it must
look for a default value in the base table.
regards,
Jaime Casanova