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

Reply via email to