Fwd: ability to return number of rows inserted into child partition tables request - Mailing list pgsql-hackers

From Roger Pack
Subject Fwd: ability to return number of rows inserted into child partition tables request
Date
Msg-id CAL1QdWf9Rg-KmpJ8gapyH5PgQdKZsVrz4NED6VBwn_hfw21YLQ@mail.gmail.com
Whole thread Raw
List pgsql-hackers

Hello.

I was trying to get postgres to return the "correct" number of rows inserted for batch inserts to a partitioned table [using the triggers as suggested here http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html results in it always returning 0 by default].

What I ideally wanted it to do is to be able to insert into just the child partitions, and return number of rows updated.

It seems the state of the art is either to return the NEW row from the insert trigger [which causes it to also be saved to the parent master table], then define an extra trigger to remove the parent table.  So 2 inserts and 1 delete for an insert. [1]

Or you can use an unconditional rule and it will return the number of rows updated [however, in this case, since we're using partitioning, we I think need multiple rules, once for each child table].  

It is possible for a view to use a trigger and still return the number of rows updated, which provides another work around. (See bottom of [1]).

Is there some more elegant way here?  It seems odd that partitioned tables basically cannot, without a *lot* of massaging, return number of rows updated, am I missing something or do I understand ok? [Today this requires people to put in lots of work arounds, like *not* checking for number of rows returned for batch inserts, etc.-- potentially dangerous as well]

Is there, for instance, some work around, like a way to manually cause the count of the number of rows affected by the command to be incremented here?  Or possibly conditional rules could be made possible to return the output string with number of rows affected (feature request)?



One way of fixing this would be to allow "do instead" rules on normal tables, instead of only on views (otherwise we are forced to use a rule, correct me if I'm wrong).  I'd wager there would be other viable options as well.

Thanks!
-roger-



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: proposal: plpgsql - Assert statement
Next
From: Mats Erik Andersson
Date:
Subject: vacuumdb: Help text for --analyze-only.