On Wed, Jun 24, 2015 at 7:38 AM, Robert Haas <robertmh...@gmail.com> wrote: > Is the root of the problem that the trigger is called for an INSERT .. > ON CONFLICT statement but it turns that into a plain INSERT? > > Is there any way of writing a partitioning trigger that doesn't have > that defect?
We did discuss whether or not it was important to expose information to triggers sufficient to route + UPSERT tuples into inheritance children in an equivalent way (equivalent to an UPSERT into the inheritance parent). At the time, you seemed to think that it could wait [1]. Even if we added what was discussed as a minimal and practical way of exposing this [2], it would still be awkward for an INSERT trigger to examine the structure of the "UPDATE part" of the UPSERT -- there will be no *tuple* for that case (yet). Inheritance with triggers is a leaky abstraction, so this kind of thing is always awkward. Still, UPSERT has full support for *inheritance* -- that just doesn't help in this case. [1] http://www.postgresql.org/message-id/ca+tgmozavxmwoebpk4aszonuwur3qpswwk6xetxmca+8h7c...@mail.gmail.com [2] http://www.postgresql.org/message-id/cam3swzrvjyu8nnvw_jhexx4ymq9xaa7u0getlbcgym0oean...@mail.gmail.com -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
