Currently we allow rules to be defined on table partitions, but these rules only fire when the partition is accessed directly, not when it is accessed via the parent:
CREATE TABLE t1(a int, b int) PARTITION BY RANGE(a); CREATE TABLE t1_p PARTITION OF t1 FOR VALUES FROM (1) TO (10); INSERT INTO t1 VALUES (1,101), (2,201); CREATE TABLE t1_p_log(a int, b int, d date); CREATE RULE t1_p_log_rule AS ON UPDATE TO t1_p DO ALSO INSERT INTO t1_p_log VALUES(old.a, old.b, now()); UPDATE t1 SET b=b+1 WHERE a=1; UPDATE t1_p SET b=b+1 WHERE a=2; SELECT * FROM t1_p_log; a | b | d ---+-----+------------ 2 | 201 | 2017-06-19 (1 row) I'd regard that as a bug, especially since this kind of thing would have worked with old-style user-defined partitioning. Perhaps we should explicitly forbid this for now -- i.e., raise a "not supported" error when attempting to add a rule to a partition, or attach a table with rules to a partitioned table. Personally, I wouldn't regard adding proper support for rules on partitions as a high priority, so I'd be OK with it remaining unsupported unless someone cares enough to implement it, but that seems preferable to leaving it partially working in this way. Also, as things stand, it is possible to do the following: CREATE TABLE t2(a int, b int) PARTITION BY RANGE(a); CREATE TABLE t2_p PARTITION OF t2 FOR VALUES FROM (1) TO (10); CREATE RULE "_RETURN" AS ON SELECT TO t2_p DO INSTEAD SELECT * FROM t2; which results in the partition becoming a view that selects from the parent, which surely ought to be forbidden. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
