tuple-routing and constraint violation error message, revisited

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: tuple-routing and constraint violation error message, revisited
Date: 2017-03-31 02:13:03
Message-ID: b3a17254-6849-e542-2353-bde4e880b6a4@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Last message regarding this was by Robert on the original partitioning thread:

https://www.postgresql.org/message-id/CA%2BTgmoZjGzSM5WwnyapFaw3GxnDLWh7pm8Xiz8_QWQnUQy%3DSCA%40mail.gmail.com

Summary is: We decided in f1b4c771ea7 [1] that passing the original slot
(one containing the tuple formatted per root partitioned table's tupdesc)
to ExecConstraints(), but that breaks certain cases. Imagine what would
happen if a BR insert trigger changed the tuple - the original slot would
not contain those changes. So, it seems better to convert (if necessary)
the tuple formatted per partition tupdesc after tuple-routing back to the
root table's format and use the converted tuple to make val_desc shown in
the message if an error occurs.

Attached rebased version of the patch that I had originally proposed
(summary above is the commit message). Robert thought it would be fine to
show the row formatted per partition rowtype, but would look better if we
could show the column names as well (remember that we're trying to account
for possible differences in the ordering of columns between the root table
and leaf partitions to which tuples are routed.)

Added this to PostgreSQL 10 open items list.

Thanks,
Amit

[1] https://git.postgresql.org/gitweb/?p=postgresql.git&a=commit&h=f1b4c77

Attachment Content-Type Size
0001-Fix-reporting-of-violation-in-ExecConstraints-again.patch text/x-diff 11.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2017-03-31 02:32:41 Re: [PATCH] Generic type subscripting
Previous Message Mengxing Liu 2017-03-31 01:41:43 Re: Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions