Re: ANSI-strict pointer aliasing rules

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, mark(at)mark(dot)mielke(dot)cc, Andrew Dunstan <andrew(at)dunslane(dot)net>, Taral <taralx(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ANSI-strict pointer aliasing rules
Date: 2006-04-27 19:56:30
Message-ID: 15068.1146167790@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Browne 2006-04-27 20:12:23 Re: Logging pg_autovacuum
Previous Message Taral 2006-04-27 19:42:35 Re: ANSI-strict pointer aliasing rules