ITAGAKI Takahiro wrote:
The chained triggers would have better flexibilty, and the auto expanding
trigger would have better usability. I'm not sure about performance
because expanding child partitions is not always faster than chained
calls of triggers.
I think chained triggers are hard to maintain. If we drop one of partition
tables, we need to reconnect the single-linked-list of the triggers.
When you drop one child table, you would also have to drop the trigger
that has the same name on the parent table. This does not seem too hard
but I may be missing something.
server says "INSERT 0 row" though rows are inserted into child tables.
Technically this is correct since 0 rows were inserted in the parent
table.
Yes, but users expect non-0 result normally. Some O/R mapping tools
also checks the result exactly and raises errors (it could be turned
off, but default is on).
If the O/R mapping tool is also creating the table it should be aware of
the semantics specifics to partition. But your comment is well taken,
this seems counterintuitive and against most API semantics to return 0
when the number of inserted rows is expected. This would certainly
require some additional hooks to return the proper value.
Best regards,
Emmanuel
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: m...@frogthinker.org
Skype: emmanuel_cecchet
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
