public inbox for [email protected]  

help / color / mirror / Atom feed

From: Matheus Alcantara <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Cc: Peter Eisentraut <[email protected]>
Cc: Yugo Nagata <[email protected]>
Subject: Re: Show expression of virtual columns in error messages
Date: Thu, 26 Feb 2026 17:29:34 -0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Thu Feb 26, 2026 at 3:47 PM -03, Tom Lane wrote:
> Matheus Alcantara <[email protected]> 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?

Thanks for the feedback. After investigating the code a bit, I found
that IIUC virtual column values are actually never computed and stored
separately, they're computed by expanding the expression wherever the
column is referenced.

According to my understanding, here's how it works during constraint
checking in ExecRelCheck():

1. The constraint expression (e.g., c > 10) is loaded from the catalog
2. Virtual column references are expanded via
expand_generated_columns_in_expr(), transforming it to (a + b) > 10 
3. ExecCheck() evaluates the entire expanded expression, reading base
column values (a, b) directly from the slot and returns the if the check
was true or false.

The virtual column value (a + b) is computed as an intermediate result
during expression evaluation of a check constraint but is never stored
anywhere accessible.

So, if all of this make sense and it's correct it seems to me that we
indeed need to compute the virtual expression value on error path to
show on error message although it would not be desirable, or I'm missing
something?

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

view thread (7+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Show expression of virtual columns in error messages
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox