This is a discussion on rewriter in updateable views within the pgsql Hackers forums, part of the PostgreSQL category; --> On Sun, 2005-03-27 at 23:12 -0500, Jaime Casanova wrote: > On Sat, 19 Mar 2005 11:42:18 +0000, Simon Riggs ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| On Sun, 2005-03-27 at 23:12 -0500, Jaime Casanova wrote: > On Sat, 19 Mar 2005 11:42:18 +0000, Simon Riggs <simon@2ndquadrant.com> wrote: > > 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... > > > I think i can do this within rewriterHandle.c:build_column_default > immediatly after the first try i can ask if expr == NULL and if is it > a view if so my code start looking for defaults on base tables maybe > using something like the parse_relation.c:colNameToVar function to > identify the column. there is a better way to do it? also the > ParseState parameter is extensively used in the colNameToVar function > but i can't find what is it. ParseState is defined in src/include/parser/parse_node.h I'm not sure I can comment further. If you have everything else working, it might be worth submitting a patch for review? There may be other things required also. Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend |
| |||
| --On Montag, März 28, 2005 09:51:52 +0100 Simon Riggs <simon@2ndquadrant.com> wrote: [...] > > If you have everything else working, it might be worth submitting a > patch for review? There may be other things required also. > > Best Regards, Simon Riggs > Well, the patch is far away from being ready for -patches, but if you want to "preview" you can get our latest patch against HEAD at http://www.oopsware.de/pgsql_viewupdate.html Critics and Discussion is highly appreciated -- Bernd ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend |
| |||
| On Tue, Mar 29, 2005 at 07:30:13PM +0200, Bernd Helmle wrote: > Well, the patch is far away from being ready for -patches, but if you want > to "preview" you can get our latest patch against HEAD at > > http://www.oopsware.de/pgsql_viewupdate.html Well, that description there says what the patch doesn't do, but it would be helpful to say what does it do. -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) "Un poeta es un mundo encerrado en un hombre" (Victor Hugo) ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings |
| ||||
| --On Mittwoch, März 30, 2005 11:35:05 -0400 Alvaro Herrera <alvherre@dcc.uchile.cl> wrote: > On Tue, Mar 29, 2005 at 07:30:13PM +0200, Bernd Helmle wrote: > >> Well, the patch is far away from being ready for -patches, but if you >> want to "preview" you can get our latest patch against HEAD at >> >> http://www.oopsware.de/pgsql_viewupdate.html > > Well, that description there says what the patch doesn't do, but it > would be helpful to say what does it do. Implemented is: - Create rules for SQL92-compliant updateable views. This creates implicit rules for DELETE, UPDATE and INSERT actions named _DELETE, _DELETE_NOTHING, _UPDATE, _UPDATE_NOTHING, _INSERT and _INSERT_NOTHING and marks them with a new column in pg_rewrite as an impicit created update rule. The patch supports system columns and functions in the view's target list rudimentary and allows CASCADED updates to base tables, since rules are created in cascaded manner on the underlying relations (which is changed, when we cover LOCAL | CASCADED CHECK OPTION). The WITH CHECK OPTION is implemented and creates all mentioned update rules with a rule condition added, which calls a new system function that elogs() an error if the passed view condition is not evaluated to true. I'm sure not all corner cases are covered for this yet, but it's still a work in progress.... -- Bernd ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq |