From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | kgrittn(at)gmail(dot)com, thomas(dot)munro(at)enterprisedb(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | RTE_NAMEDTUPLESTORE, enrtuples and comments |
Date: | 2017-06-11 06:25:25 |
Message-ID: | 20170611062525.GA1628882@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While completing my annual src/backend/nodes/*funcs.c audit, I noticed defects
in commit 18ce3a4 changes to RangeTblEntry:
1. Field relid is under a comment saying it is valid for RTE_RELATION only.
Fields coltypes, coltypmods and colcollations are under a comment saying
they are valid for RTE_VALUES and RTE_CTE only. But _outRangeTblEntry()
treats all of the above as valid for RTE_NAMEDTUPLESTORE. Which is right?
2. New fields enrname and enrtuples are set only for RTE_NAMEDTUPLESTORE, yet
they're under the comment for RTE_VALUES and RTE_CTE. This pair needs its
own comment.
3. Each of _{copy,equal,out,read}RangeTblEntry() silently ignores enrtuples.
_equalRangeTblEntry() ignores enrname, too. In each case, the function
should either use the field or have a comment to note that skipping the
field is intentional. Which should it be?
This fourth point is not necessarily a defect: I wonder if RangeTblEntry is
the right place for enrtuples. It's a concept regularly seen in planner data
structures but not otherwise seen at parse tree level.
nm
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2017-06-11 11:11:58 | Re: RTE_NAMEDTUPLESTORE, enrtuples and comments |
Previous Message | Mark Kirkwood | 2017-06-11 05:11:15 | Re: Make ANALYZE more selective about what is a "most common value"? |