Re: Pgoutput not capturing the generated columns - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Pgoutput not capturing the generated columns
Date
Msg-id CAHut+PsefzJNr6hsVTh3d4kL5gf6tCDh9G_aXcrriWLoJRZ6OQ@mail.gmail.com
Whole thread Raw
In response to Re: Pgoutput not capturing the generated columns  (Shlok Kyal <shlok.kyal.oss@gmail.com>)
Responses Re: Pgoutput not capturing the generated columns
List pgsql-hackers
Hi Shubham/Shlok, I was thinking some more about the suggested new
BitMapSet (BMS) idea of patch 0001 that changes the 'columns' meaning
to include generated cols also where necessary.

I feel it is a bit risky to change lots of code without being 100%
confident it will still be in the final push. It's also going to make
the reviewing job harder if stuff gets added and then later removed.

IMO it might be better to revert all the patches (mostly 0001, but
also parts of subsequent patches) to their pre-BMS-change ~v14* state.
Then all the BMS "improvement" can be kept isolated in a new patch
0004.

Some more reasons to split this off into a separate patch are:

* The BMS change is essentially a redesign/cleanup of the code but is
nothing to do with the actual *functionality* of the new "generated
columns" feature.

* Apart from the BMS change I think the rest of the patches are nearly
stable now. So it might be good to get it all finished so the BMS
change can be tackled separately.

* By isolating the BMS change, then we will be able to see exactly
what is the code cost/benefit (e.g. removal of redundant code versus
adding new logic) which is part of the judgement to decide whether to
do it this way or not.

* By isolating the BMS change, then it makes it convenient for testing
before/after in case there are any performance concerns

* By isolating the BMS change, if some unexpected obstacle is
encountered that makes it unfeasible then we can just throw away patch
0004 and everything else (patches 0001,0002,0003) will still be good
to go.

Thoughts?

======
Kind Regards,
Peter Smith.
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Next
From: Andres Freund
Date:
Subject: Re: Should we work around msvc failing to compile tab-complete.c?