Horton

Re: Virtual generated columns

vignesh C <vignesh21@gmail.com>

View thread
From: vignesh C <vignesh21@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, jian he <jian.universality@gmail.com>
Date: 2025-02-06T13:03:11Z
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__.

On Wed, 5 Feb 2025 at 04:06, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 27.01.25 13:42, Dean Rasheed wrote:
> > On Mon, 27 Jan 2025 at 09:59, Peter Eisentraut <peter@eisentraut.org> wrote:
> >>
> >> 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.
> >>
> >
> > In struct ResultRelInfo, the following field is added:
> >
> >      int         ri_NumGeneratedNeededI;
> >      int         ri_NumGeneratedNeededU;
> >
> > +   /* true if the above have been computed */
> > +   bool        ri_Generated_valid;
> > +
> >
> > but that doesn't really seem to be accurate, because it's set to true
> > by ExecInitGenerated() whether it's called with CMD_INSERT or
> > CMD_UPDATE, so it will be true before both the other fields are
> > computed. It's used from ExecGetExtraUpdatedCols() as an indicator
> > that ri_extraUpdatedCols is valid, but it looks like that might not be
> > the case, if ExecInitGenerated() was only called with CMD_INSERT.
> >
> > I'm not sure if that represents an actual bug, but it looks wrong. It
> > should perhaps be called "ri_extraUpdatedCols_valid", and only set to
> > true when ExecInitGenerated() is called with CMD_UPDATE, and
> > ri_extraUpdatedCols is populated.
>
> Yeah, this is quite contorted.  I have renamed it like you suggested.

One suggestion: for the option where the user specifies
publish_generated_columns as virtual (as shown below), could we change
the error indicating that virtual generated columns are not currently
supported?
CREATE PUBLICATION pub1 FOR TABLE t1 WITH (publish_generated_columns = virtual);

Also, could we add a XXX comment in either decode.c, pgoutput.c, or
publicationcmds.c outlining what would be needed to support the
replication of virtual generated columns? Specifically, it would be
helpful if we could include how to retrieve virtual generated column
data during decoding. This would serve as a reference for anyone
working on enabling logical replication of virtual generated columns
in the future.

Regards,
Vignesh