Re: Show expression of virtual columns in error messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(at)eisentraut(dot)org>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Subject: Re: Show expression of virtual columns in error messages
Date: 2026-02-26 18:47:07
Message-ID: 719803.1772131627@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Matheus Alcantara <matheusssilv97(at)gmail(dot)com> writes:
> Attached rebased v3 due to f80bedd52b1. No additional changes compared
> to v2.

I looked at this and frankly I think it's going in the wrong
direction. I agree that showing "virtual" is unhelpful, but
I don't like this approach for a couple of reasons:

1. Inserting a column expression could easily make the error
message annoyingly long.

2. Adding this much complexity in an error code path doesn't
seem like a good idea. Such paths are typically not well
tested, and if there is any bug lurking, it will result in
an error message quite removed from the user's problem.

3. It's making virtual generated columns behave (even more)
differently from stored generated columns. I think the
general plan has been to make them act as alike as possible.

So what would comport better with the behavior of stored columns
is to show the expression's value. I agree with you that
calculating that in the error path is a no-go, but haven't we
computed it earlier? Or could we do so, if there are constraints
to be checked?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2026-02-26 19:11:31 Re: Non-text mode for pg_dumpall
Previous Message David G. Johnston 2026-02-26 18:39:57 Partial Mode in Aggregate Functions