Horton

Re: Virtual generated columns

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: jian he <jian.universality@gmail.com>, Dean Rasheed <dean.a.rasheed@gmail.com>
Date: 2025-01-27T09:59:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Expand virtual generated columns for ALTER COLUMN TYPE

  2. Eliminate code duplication in replace_rte_variables callbacks

  3. Expand virtual generated columns in the planner

  4. Virtual generated columns

  5. Additional tests for stored generated columns

  6. Improve generated_stored test

  7. Fix handling of CREATE DOMAIN with GENERATED constraint syntax

  8. Add pg_constraint rows for not-null constraints

  9. Put generated_stored test objects in a schema

  10. Rename regress test generated to generated_stored

  11. Small code simplification

  12. Remove useless code

  13. Remove useless initializations

  14. doc: Clarify that pg_attrdef also stores generation expressions

  15. Clean out column-level pg_init_privs entries when dropping tables.

  16. Re-implement the ereport() macro using __VA_ARGS__.

Attachments

On 15.01.25 20:37, Peter Eisentraut wrote:
> On 15.01.25 15:12, Dean Rasheed wrote:
>> On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut <peter@eisentraut.org> 
>> wrote:
>>>
>>> Here is a new patch with that fixed and also a few
>>> tweaks suggested by Jian.
>>>
>>
>> I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
>> that I would check how it works together with this patch. The good
>> news is that AFAICS everything just works, and it's possible to return
>> old/new virtual generated columns in DML queries as expected.
>>
>> It did require a minor update, because my patch adds a new
>> "result_relation" argument to ReplaceVarsFromTargetList() -- needed in
>> DML queries because, when propagating a Var's old/new
>> varreturningtype, replacement Vars need to be handled differently
>> depending on whether or not they refer to the result relation. So that
>> affects expand_generated_columns_internal(), when called from
>> fireRIRrules(). OTOH, from expand_generated_columns_in_expr() it's OK
>> to just pass 0 as the result relation index, because there won't be
>> any old/new Vars in an expression that's not part of a DML query.
>>
>> Attached is the delta patch I used to handle this, along with a couple
>> of simple test cases. It doesn't really matter which feature makes it
>> in first, but the one that comes second will need to do something like
>> this.
> 
> Ok, I'll wait if you want to go ahead with yours soon.

Here is an updated patch that integrates the above changes and also 
makes some adjustments now that the logical replication configuration 
questions are resolved.  I think this is complete now.

But I'm seeing mysterious CI failures that have me stumped.  For example:

https://cirrus-ci.com/task/5924251028422656

I have seen this particular pgbench test failure sporadically but 
several times, and I have not seen it anywhere without this patch, and 
never locally.  The macOS task on the cfbot CI is very flaky right now, 
so it's hard to get a good baseline.  Also, it seems to me that this 
failing test could not possibly be further away from the code that the 
patch changes, so I'm thinking timing problems, but it only happens on 
the macOS task.  Really weird.