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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
