| From: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> |
|---|---|
| To: | "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>, <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Show expression of virtual columns in error messages |
| Date: | 2026-02-04 17:54:11 |
| Message-ID: | DG6DBW8NDTJC.1U9ELI7JCWOEB@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed Feb 4, 2026 at 11:57 AM -03, Peter Eisentraut wrote:
> On 03.02.26 15:06, Matheus Alcantara wrote:
>> The attached patch changes this behavior to show the virtual column
>> expression instead:
>>
>> ERROR: new row for relation "t" violates check constraint "t_c_check"
>> DETAIL: Failing row contains (5, 10, a * 2).
>
> Could be useful, but in this context you don't know which column is "a"?
I agree but we at least show more information to the user. The user may
still need to check the table definition to understand the constraint or
to get the column ordering of the table to understand what the value of
"a" is being used to compute the expression.
If the statement declare the columns that the values are referecing this
could be easier to know (e.g INSERT INTO t(a, b) VALUES (5, 10)) but the
user may still need to check the table definition to understand the
constraint.
I see this patch as a way to at least give more information to user
about the error.
Another possibility would be to get the actual values of "a" for example
and show it on the error message, e.g:
ERROR: new row for relation "t" violates check constraint "t_c_check"
DETAIL: Failing row contains (5, 10, 5 * 2).
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-02-04 18:27:43 | Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects |
| Previous Message | Zsolt Parragi | 2026-02-04 17:44:06 | Re: Pasword expiration warning |