On 2020-03-12 05:17, Ashutosh Bapat wrote:
> On Wed, Mar 11, 2020 at 8:53 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
>> Will it be easier to subject the new tuple to the partition level
>> constraints themselves and report if those are violated. See
>> RelationGetPartitionQual() for getting partition constraints. This
>> function includes partition constraints from all the levels so in your
>> function you don't have to walk up the partition tree. It includes
>> constraints from the level above the table that was named in the
>> command, but that might be fine. We will catch the error earlier and
>> may be provide a better error message.
>
> I realized that this will implement the third option in your original
> proposal, not the second one. I suppose that's fine too?
It might be that that is actually easier to do. Instead of trying to
figure out which columns have changed, in the face of different column
ordering and general expressions, just check after a trigger whether the
column still fits into the partition.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services