[sorry if this mail appears more than once, but it seems the others didn't make it through the list]

This is a short preview on the view update code i'm currently working on. It is far away from being ready, but i want to share the current code and get some hints, what things have to be made better:

http://www.oopsware.de/pgsql/pgsql-view_update.tar.gz

The patchfile is against beta4, view_update.h belongs to src/include/rewrite, view_update.c to src/backend/rewrite. The code requires an initdb, however, the catalog change contained in this code is used but not very useful yet.

The code has the following known problems:

- User defined update rules on views are created without any intervention from the code. This is why the rule regression tests (and others) fails, because there suddenly are two INSERT/UPDATE/DELETE rules....

- Indexed array fields in a view columns list causes SIGSEGV (due to some experiments i do with array subscripting operations).

- There are problems with NULL fields in WHERE conditions.

- gram.y is only an ugly hack to get the CHECK OPTION working. needs deeper efforts, because it makes WITH a reserved keyword....

The following items needs deeper discussion i think:

- DEFAULT values on the underlying base tables needs to be specified explicitly to the view itself (via ALTER TABLE), another problem are SERIALs ...
- What should happen, if someone throws a pg_dump or sql script at the backend, that holds own update rules for a view? in this case the implicit ones should be removed or deactivated ....
- the code only supports cascaded rules and all rules are created on the base relations only. So if one underlying base relation is not updateable, the view itself is not updateable, too.



-- TIA Bernd

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to