Re: rewriter in updateable views
От | Bernd Helmle |
---|---|
Тема | Re: rewriter in updateable views |
Дата | |
Msg-id | 31A45F5066A818D47FBE000D@sparkey.oopsware.intra обсуждение исходный текст |
Ответ на | Re: rewriter in updateable views (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
--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
В списке pgsql-hackers по дате отправления: