| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:03:47 |
| Message-ID: | 101171fc-da4c-7799-991d-65ad84f53d7d@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Juan José Santamaría Flecha | 2022-07-12 19:32:33 | Re: WIN32 pg_import_system_collations |
| Previous Message | Peter Eisentraut | 2022-07-12 18:58:53 | Re: Making CallContext and InlineCodeBlock less special-case-y |