From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Making CallContext and InlineCodeBlock less special-case-y |
Date: | 2022-07-12 18:58:53 |
Message-ID: | 9fdda793-ba84-2fcf-077b-af870892b573@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12.07.22 01:01, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>>> On 10.07.22 01:50, Tom Lane wrote:
>>>> As committed, gen_node_support.pl excludes CallContext and InlineCodeBlock
>>>> from getting unneeded support functions via some very ad-hoc code.
>
>>> Couldn't we just enable those support functions? I think they were just
>>> excluded because they didn't have any before and nobody bothered to make
>>> any.
>
>> Well, we could I suppose, but that path leads to a lot of dead code in
>> backend/nodes/ --- obviously these two alone are negligible, but I want
>> a story other than "it's a hack" for execnodes.h and the other files
>> we exclude from generation of support code.
>
> Here's a proposed patch for this bit. Again, whether these two
> node types have unnecessary support functions is not the point ---
> obviously we could afford to waste that much space. Rather, what
> I'm after is to have a more explainable and flexible way of dealing
> with the file-level exclusions applied to a lot of other node types.
> This patch doesn't make any change in the script's output now, but
> it gives us flexibility for the future.
Yeah, looks reasonable.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-07-12 19:03:47 | Re: automatically generating node support functions |
Previous Message | Peter Eisentraut | 2022-07-12 18:56:36 | Re: System catalog documentation chapter |