--On Dienstag, Oktober 26, 2004 13:02:27 +0200 Bernd Helmle
<mailings@oopsware.de> wrote:
> [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.
Sorry, forgot the subject :(
--
Bernd
