Re: ANSI-strict pointer aliasing rules - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ANSI-strict pointer aliasing rules
Date
Msg-id 15068.1146167790@sss.pgh.pa.us
Whole thread Raw
In response to Re: ANSI-strict pointer aliasing rules  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Doesn't achieve the same thing, unless you mandate that every part of
>> the system use the identical massively-overloaded union struct to refer
>> to every node.  

> Are you saying it's important to preserve the ability for modules to add new
> node types without notifying the rest of the code? I thought all the node
> types were defined in a single header file currently anyways.

No, they're scattered through at least half a dozen headers.  We don't
really have "dynamic" extensibility because the NodeTag enum is declared
in just one place, but we do have separation of concerns: stuff dealing
with parsenodes.h need not import all the executor node types, for
instance.  The big objection to a single-union-struct approach is that
it forecloses any locality of knowledge about node types.

(I also wonder how many compilers would give up the ghost entirely on
being fed a union type of 250+ separate structs, with in aggregate
several thousand fields ... and even if they didn't fail, how fast
they'd compile code making heavy use of such a beast.)

> It would be pretty cool to have a type-safe codebase. It just seems like too
> an awful lot of work for a mostly aesthetic improvement.

Yeah, I think that's how we all feel.  I'd not even waste any time
thinking about it, except that I'm afraid the compiler guys may
eventually stop supporting the traditional semantics ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Taral
Date:
Subject: Re: ANSI-strict pointer aliasing rules
Next
From: Chris Browne
Date:
Subject: Re: Logging pg_autovacuum