Re: ANSI-strict pointer aliasing rules

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ANSI-strict pointer aliasing rules
Дата
Msg-id 15068.1146167790@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ANSI-strict pointer aliasing rules  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Taral
Дата:
Сообщение: Re: ANSI-strict pointer aliasing rules
Следующее
От: Chris Browne
Дата:
Сообщение: Re: Logging pg_autovacuum