On 02/06/16 20:01, rverghese wrote:
> We are looking to move from one large table to partitioned tables. Since the
> inserts and updates are made to the master table and then inserted into the
> appropriate partitioned table based on the trigger rules, the affected_rows
> returned to the client (PHP in this case) is always 0. We have been using
> the affected_rows to check various things on the client end. Is there an
> alternative to check for rows affected with partitioned tables? Seems like a
> pretty big missing feature.
The standard way to do partitioning is for the trigger on the parent
table to redirect the INSERT and then cancel the original INSERT by
returning NULL. It sounds like that's what you're doing, and since the
INSERT command that you actually gave didn't insert any rows, you
correctly get 0 back.
The solution to this, which is a little ugly but works, is to create a
view over the parent table with an INSTEAD OF trigger and insert into
the view.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support