On Thu, Mar 30, 2023 at 4:06 AM Pavel Stehule <pavel.steh...@gmail.com> wrote:
> Hi > > ne 26. 3. 2023 v 19:44 odesílatel Dmitry Dolgov <9erthali...@gmail.com> > napsal: > >> > On Fri, Mar 24, 2023 at 08:04:08AM +0100, Pavel Stehule wrote: >> > čt 23. 3. 2023 v 19:54 odesílatel Pavel Stehule < >> pavel.steh...@gmail.com> >> > napsal: >> > >> > > čt 23. 3. 2023 v 16:33 odesílatel Peter Eisentraut < >> > > peter.eisentr...@enterprisedb.com> napsal: >> > > >> > >> The other issue is that by its nature this patch adds a lot of code >> in a >> > >> lot of places. Large patches are more likely to be successful if >> they >> ... >> I agree, the patch scale is a bit overwhelming. It's worth noting that >> due to the nature of this change certain heavy lifting has to be done in >> any case, plus I've got an impression that some part of the patch are >> quite solid (although I haven't reviewed everything, did anyone achieve >> that milestone?). But still, it would be of great help to simplify the >> current implementation, and I'm afraid the only way of doing this is to >> make trades-off about functionality vs change size & complexity. >> > > There is not too much space for reduction - more - sometimes there is code > reuse between features. > > I can reduce temporary session variables, but the same AtSubXact routines > are used by memory purging routines, and if only if you drop all dependent > features, then you can get some interesting number of reduced lines. I can > imagine very reduced feature set like > > 1) no temporary variables, no reset at transaction end > 2) without default expressions - default is null > 3) direct memory cleaning on drop (without possibility of saved value > after reverted drop) or cleaning at session end always > > Note - @1 and @3 shares code > > Please don't remove #2. With Default Values, I was eyeballing these as pseudo constants. I find I have a DRY (Don't Repeat Yourself) issue in our current code base (PLPGSQL) because of the lack of shared constants throughout the application layer. We literally created a CONST schema with SQL functions that return a set value. It's kludgy, but clear enough. (We have approximately 50 of these). Regards, Kirk
