From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Missing dependency tracking for TableFunc nodes
Date: Tue, 12 Nov 2019 10:19:30 -0500
Message-ID: <1690.1573571970@sss.pgh.pa.us> (raw)
In-Reply-To: <42282535-a0a2-f2cf-c769-262f870bec9b@gmail.com>
References: <18427.1573508501@sss.pgh.pa.us>
<352b500b-9bf5-6e6a-fcf4-d9847738e977@gmail.com>
<42282535-a0a2-f2cf-c769-262f870bec9b@gmail.com>
Mark Dilger <hornschnorter@gmail.com> writes:
> I played with this a bit, making the change I proposed, and got lots of
> warnings from the compiler. I don't know how many of these would need
> to be suppressed by adding a no-op for them at the end of the switch vs.
> how many need to be handled, but the attached patch implements the idea.
> I admit adding all these extra cases to the end is verbose....
Yeah, that's why it's not done that way ...
> The change as written is much too verbose to be acceptable, but given
> how many places in the code could really use this sort of treatment, I
> wonder if there is a way to reorganize the NodeTag enum into multiple
> enums, one for each logical subtype (such as executor nodes, plan nodes,
> etc) and then have switches over enums of the given subtype, with the
> compiler helping detect tags of same subtype that are unhandled in the
> switch.
The problem here is that the set of nodes of interest can vary depending
on what you're doing. As a case in point, find_expr_references has to
cover both expression nodes and some things that aren't expression nodes
but can represent dependencies of a plan tree.
I think that the long-term answer, if Andres gets somewhere with his
project to autogenerate code like this, is that we'd rely on annotating
the struct declarations to tell us what to do. In the case at hand,
I could imagine annotations that say "this field contains a function OID"
or "this list contains collation OIDs" and then the find_expr_references
logic could be derived from that. Now, that's not perfect either, because
it's always possible to forget to annotate something. But it'd be a lot
easier, because there'd be tons of nearby examples of doing it right.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, hornschnorter@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Missing dependency tracking for TableFunc nodes
In-Reply-To: <1690.1573571970@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox