Re: Using Expanded Objects other than Arrays from plpgsql - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Using Expanded Objects other than Arrays from plpgsql
Date
Msg-id 932C9840-63D6-469D-9C65-1B1A14594D29@yandex-team.ru
Whole thread Raw
In response to Re: Using Expanded Objects other than Arrays from plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Using Expanded Objects other than Arrays from plpgsql
List pgsql-hackers

> On 3 Feb 2025, at 02:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I decided to see what would happen if we tried to avoid the code
> duplication in pl_funcs.c by making some "walker" infrastructure
> akin to expression_tree_walker.  While that doesn't seem useful
> for the dump_xxx functions, it works very nicely for the free_xxx
> functions and now for the mark_xxx ones as well.  pl_funcs.c
> nets out about 400 lines shorter than in the v4 patch.  The
> code coverage score for the file is still awful :-(, but that's
> because we're not testing the dump_xxx functions at all.
>
> PFA v5.  The new 0001 patch refactors the free_xxx infrastructure
> to create plpgsql_statement_tree_walker(), and then in what's now
> 0003 we can use that instead of writing a lot of duplicate code.


Pre-preliminary refactoring looks good to me, as the rest of the patch set.

(Well, maybe paramarg2 resonates a bit, just from similarity with varchar2)

ecpg tests seem to fail on Windows[0], but looks like it's not related to this thread.


Best regards, Andrey Borodin.

[0] https://cirrus-ci.com/task/4835794898124800


pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Show WAL write and fsync stats in pg_stat_io
Next
From: Amit Kapila
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation