--On Samstag, März 19, 2005 11:05:39 -0500 Tom Lane <[EMAIL PROTECTED]> wrote:

Jaime Casanova <[EMAIL PROTECTED]> writes:
On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to