Peter Geoghegan <p...@bowt.ie> writes:
> On Fri, Jan 29, 2021 at 12:12 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I got annoyed (not for the first time) by the fact that the
>> partitioned_rels field of AppendPath and MergeAppendPath is a list of
>> Relids, i.e., Bitmapsets. This is problematic because a Bitmapset is
>> not a type of Node, and thus a List of them is really an invalid data
>> structure. The main practical consequence is that pprint() fails to
>> print these path types accurately, which is an issue for debugging.
> So we don't actually require T_List-type Lists to only contain entries
> of type Node already?
I seem to recall that there are some places that use Lists to store
plain "char *" strings (not wrapped in T_String), and there are
definitely places that use lists of non-Node structs. That's a kluge,
but I don't really object to it in narrowly-scoped data structures.
I think it's a good bit south of acceptable in anything declared in
include/nodes/*.h, though. Publicly visible Node types ought to be
fully manipulable by the standard backend/nodes/ functions.
> ISTM that T_List-type Lists cannot *mostly* be a
> Node that consists of a collection of linked Nodes. It has to be
> all-or-nothing.
Right. Any situation where you have a List of things that aren't
Nodes has to be one where you know a-priori that everything in this
List is a $whatever. If the List is only used within a small bit
of code, that's fine, and adding the overhead to make the contents
be real Nodes wouldn't be worth the trouble.
> It's probably much riskier to use 32-bit x86 today than
> it is to use (say) POWER8, or some other contemporary minority
> platform.
We do still have x86 in the buildfarm, as well as some other
32-bit platforms, so I don't agree that it's that much less
tested than non-mainstream 64-bit platforms. But I do agree
it's not our main development focus anymore, and shouldn't be.
regards, tom lane
