Re: Making CallContext and InlineCodeBlock less special-case-y

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.

In response to

Browse pgsql-hackers by date

  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