Re: automatically generating node support functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: automatically generating node support functions
Date: 2022-07-12 19:49:11
Message-ID: 1739895.1657655351@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 11.07.22 19:57, Tom Lane wrote:
>> So at this point I'm rather attracted to the idea of reverting to
>> a manually-maintained NodeTag enum. We know how to avoid ABI
>> breakage with that, and it's not exactly the most painful part
>> of adding a new node type.

> One of the nicer features is that you now get to see the numbers
> assigned to the enum tags, like

> T_LockingClause = 91,
> T_XmlSerialize = 92,
> T_PartitionElem = 93,

> so that when you get an error like "unsupported node type: %d", you can
> just look up what it is.

Yeah, I wasn't thrilled about reverting that either. I think the
defenses I installed in eea9fa9b2 should be sufficient to deal
with the risk.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-12 20:31:39 Re: should check interrupts in BuildRelationExtStatistics ?
Previous Message Tom Lane 2022-07-12 19:45:43 Re: Remove trailing newlines from pg_upgrade's messages