[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

On T, 2004-10-26 at 14:02, Bernd Helmle wrote:

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

IMHO it should be a reserved keyword. I once wrangled to fit ANSI SQL
recursive queries into postgres grammar and the only way I could do that
also forced me to make WITH a reserved keyword.

Thus I think that reserved keyword is what it is meant to be in the
first place ;)

----------
Hannu

--On Dienstag, Oktober 26, 2004 23:44:10 +0300 Hannu Krosing <hannu(at)tm(dot)ee>
wrote:

>
> Thus I think that reserved keyword is what it is meant to be in the
> first place ;)

Yes, that was my intention, too. That's because i went straight forward and
put it in the reserved keyword list and didn't spent time on playing around
with it as a non-reserved keyword. I expect somebody wouldn't agree with
this, since it will break things if somebody has something odd like

CREATE VIEW vblabla
AS
SELECT
*
FROM
FOO AS WITH;

--

Bernd