--On Dienstag, Oktober 26, 2004 13:02:27 +0200 Bernd Helmle
<[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
