Hi,
> I had raised this issue about rules/triggers back then and the
> responses seemed to be evenly split as to which ones to use.
Presumably your implementation already uses Triggers for INSERTs though,
so why not use triggers for everything?
No I am using rules for all the 3 cases. I am done with the UPDATE stuff too on which I was stuck with some help, so here is what the patch will do:
postgres=# create table test1 (a int unique , b int check (b > 0)) partition by range(a) (partition child_1 check (a < 10));
NOTICE: CREATE TABLE / UNIQUE will create implicit index "test1_a_key" for table "test1"
NOTICE: CREATE TABLE / UNIQUE will create implicit index "child_1_a_key" for table "child_1"
CREATE TABLE
A describe of the parent shows the rules added to it:
postgres=# \d test1
Table "public.test1"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
b | integer |
Indexes:
"test1_a_key" UNIQUE, btree (a)
Check constraints:
"test1_b_check" CHECK (b > 0)
Rules:
test1_child_1_delete AS
ON DELETE TO test1
WHERE old.a < 10 DO INSTEAD DELETE FROM child_1
WHERE child_1.a = old.a
test1_child_1_insert AS
ON INSERT TO test1
WHERE new.a < 10 DO INSTEAD INSERT INTO child_1 (a, b)
VALUES (new.a, new.b)
test1_child_1_update AS
ON UPDATE TO test1
WHERE old.a < 10 DO INSTEAD UPDATE child_1 SET a = new.a, b = new.b
WHERE child_1.a = old.a
Whereas a describe on the child shows the following:
postgres=# \d child_1
Table "public.child_1"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
b | integer |
Indexes:
"child_1_a_key" UNIQUE, btree (a)
Check constraints:
"child_1_a_check" CHECK (a < 10)
"test1_b_check" CHECK (b > 0)
Inherits: test1
Regards,
Nikhils
--
EnterpriseDB
http://www.enterprisedb.com