cale@sun1.ruf.uni-freiburg.de (Peter Caligari) (05/17/91)
We recently implemented the KNOWLEDGE MANAGER in INGRES and I tried to make
a view, spanning two different tables, behave exactly like a table. This
idea was brought up to me by POSTGRES.
Here is what I did:
CREATE TABLE a(
nr i4 NOT NULL NOT DEFAULT,
a_feld C10 WITH NULL
);
CREATE TABLE ref(
nr I4 NOT NULL NOT DEFAULT
);
CREATE TABLE b(
nr I4 NOT NULL NOT DEFAULT,
b_feld C10 WITH NULL
);
CREATE VIEW c AS SELECT a.a_feld,b.b_feld FROM a,b
WHERE a.nr = b.n;
CREATE PROCEDURE proc_insert_c (a_feld C10,b_feld C10) AS
DECLARE
i INTEGER;
BEGIN
SELECT i = MAX(nr) FROM ref;
INSERT INTO a (nr,a_feld) VALUES (:i,:a_feld);
INSERT INTO b (nr,b_feld) VALUES (:i,:b_feld);
END;
CREATE RULE insert_c AFTER INSERT INTO c
EXECUTE PROCEDURE proc_insert_c (a_feld = new.a_feld,b_feld = new.b_feld);
This is the error I got, when issuing the last statement:
E_US18A4 CREATE RULE: Rules cannot be applied to a view 'c'.
So my question is will this be able in further releases of INGRES?
I think such a thing would be highly desireable. A common situation at ours
is the following:
People decide to buy INGRES. However, they don't want to be bothered by
programing an application, so they use QBF or SQL. To retain referential
integrety they also buy the KNOWLEDGE MANAGER. Now they get real support
by us only during the design phase of their database. We help them creating
all their tables, and to formulate the rules.
When dividing up their structures into tables, they normally get a little
upset because of all the unique identifiers you have to introduce to
identify a row in some table.
The method described above would be very nice, because you can join
locically distinct data to a somewhat convenient view, which looks more
comfortable to the end user and which he can use instead of the
two tables below it.
I'm really courios to your opinion on this point.
Thanks in advance.
Peter Caligari (cale@sun1.ruf.uni-freiburg.de)