Re: BEFORE ROW triggers for partitioned tables

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, ashutosh(dot)bapat(at)2ndquadrant(dot)com
Subject: Re: BEFORE ROW triggers for partitioned tables
Date: 2020-03-13 07:28:20
Message-ID: ccc6e8c2-f53a-5a55-d0eb-09adcab5b0fd@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-03-12 05:17, Ashutosh Bapat wrote:
> On Wed, Mar 11, 2020 at 8:53 PM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Victor Wagner 2020-03-13 07:29:13 make check crashes on POWER8 machine
Previous Message Kyotaro Horiguchi 2020-03-13 07:21:13 Re: Reducing WaitEventSet syscall churn