Thread:

[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@tm.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