From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com> |
Subject: | Re: Virtual generated columns |
Date: | 2025-02-06 13:03:11 |
Message-ID: | CALDaNm3Y5Dx2fPcPprhoof4CbxG9+XKM4q7LuERNaAtNThhmcQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 5 Feb 2025 at 04:06, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 27.01.25 13:42, Dean Rasheed wrote:
> > On Mon, 27 Jan 2025 at 09:59, Peter Eisentraut <peter(at)eisentraut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2025-02-06 13:07:37 | Re: Docs for pg_basebackup needs v17 note for incremental backup |
Previous Message | Jelte Fennema-Nio | 2025-02-06 12:53:03 | Re: new commitfest transition guidance |