--On Samstag, März 19, 2005 11:05:39 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
> Jaime Casanova <systemguards@gmail.com> writes:
>> On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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?
>
> So? Being able to have a different default for the view could be
> construed as a feature, not a bug.
>
As far as i can oversee, we have the following options to handle this:
1.
- Create default values in views inherited by their base tables in the
CREATE VIEW command.
- Extend ALTER TABLE table ... SET DEFAULT ... to track dependencies when
changing default values in base tables. We need to know, when a default
value in a view was overwritten by a user-fired ALTER TABLE view ... SET
DEFAULT, so we need some extra information somewhere. I think the plus of
this implementation is, that we don't touch the rewriter and don't need
extra time on rewriting a query. The negative is that this adds
side-effects to ALTER TABLE ... SET DEFAULT ... when views are involved.
2.
Extend the rewriter (rewriteTargetList()) to derive column default values
from a base table, if the pg_attribute.atthasdef column value is set to
false and the base table has a valid default expression. This adds extra
time when rewriting the target list of a query and we need to reparse the
query tree to find out which base table(s) /columns to look for, if we
don't save extra information somewhere, but we don't have the overhead of
keeping views and base tables in sync....
--
Bernd
