BUG #2671: incorrect return value by RULE

The following bug has been logged online:

Bug reference: 2671
Logged by: Toru SHIMOGAKI
Email address: shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp
PostgreSQL version: 8.1.4/8.2beta1
Operating system: Red Hat Enterprise Linux AS4
Description: incorrect return value by RULE
Details:

Hi, all;

It seems a bug that incorrect return value is displayed if RULE is applied
(RULE is always used when users use table partitioning). This is undesirable
for some users and applications that want to check return value.

The following is the procedure:

=====================================================================

postgres=# \d test_p;
Table "public.test_p"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
Rules:
rule_1 AS
ON INSERT TO test_p
WHERE new.a >= 0 DO INSTEAD INSERT INTO test_c1 (a)
VALUES (new.a)
rule_2 AS
ON INSERT TO test_p
WHERE new.a < 0 DO INSTEAD INSERT INTO test_c2 (a)
VALUES (new.a)

postgres=# \d test_c1;
Table "public.test_c1"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
Inherits: test_p

postgres=# \d test_c2;
Table "public.test_c2"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
Inherits: test_p

postgres=# INSERT INTO test_p VALUES (1);
INSERT 0 0
^^^ The expected result is "INSERT 0 1"

=====================================================================

At least, this behavior is different from the following discription of
INSERT manual;

=====================================================================

...

Outputs

On successful completion, an INSERT command returns a command tag of the
form

INSERT oid count

The count is the number of rows inserted. If count is exactly one, and the
target table has OIDs, then oid is the OID assigned to the inserted row.
Otherwise oid is zero.

...
=====================================================================

We need some specifications to solve this problem. I think that to fix it
seems not so easy, because RULE has DO ALSO/DO INSTEAD and we have to
consider them for a query multiple RULES are applied.

Are there any good ideas to avoid or fix it?

Best regards,

--
Toru SHIMOGAKI<shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>
NTT Open Source Software Center