Re: Proposal: make "opaque" obsolete

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal: make "opaque" obsolete
Дата
Msg-id 20229.1029940388@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal: make "opaque" obsolete  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> I'll give it a shot, but a crude gameplan/general guidance to get me 
> started would be much appreciated.

AFAIK, the only code you should need to touch is
insrc/include/utils/array.hsrc/backend/utils/adt/arrayfuncs.csrc/backend/utils/adt/arrayutils.c

Look around for other references to ArrayType, but I don't *think* there
is anything else that processes arrays directly; everything else
should be calling construct_array() or deconstruct_array().

Adding an element-type OID field to the array header (ArrayType struct)
ought to be a pretty straightforward exercise.  We need to debate
whether to store a typmod as well; I'm not sure that the space for it
would be justified.

The other thing that was bothering me was that the code is sloppy about
alignment: although the overall start of the data area is correctly
MAXALIGN'd, the offsets of individual data items in the array aren't
necessarily made to be multiples of the element data type's alignment
spec.  This would probably result in core dumps for datatypes whose size
is not a multiple of their alignment requirement.  (The only standard
one is INTERVAL.  For reasons I've never quite figured out, an array
of INTERVAL doesn't provoke core dumps; seems like it should, at least
on machines where doubles actually require 8-byte alignment.)  There are
a dozen or two places in arrayfuncs.c that understand the alignment
conventions for array elements, and they all need to be changed.  The
att_align macro in src/include/access/tupmacs.h is probably the thing
to be using; look at the code in heaptuple.c to see how we position
field values inside a tuple, and do likewise.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: CVS broken - large file support?
Следующее
От: Sir Mordred The Traitor
Дата:
Сообщение: i'll promise, i'll be polite :-)