From: | Gregory Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Variable length varlena headers redux |
Date: | 2007-02-09 03:31:01 |
Message-ID: | 87sldghuru.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I've been looking at this again and had a few conversations about it. This may
be easier than I had originally thought but there's one major issue that's
bugging me. Do you see any way to avoid having every user function everywhere
use a new macro api instead of VARDATA/VARATT_DATA and VARSIZE/VARATT_SIZEP?
The two approaches I see are either
a) To have two sets of macros, one of which, VARATT_DATA and VARATT_SIZEP are
for constructing new tuples and behaves exactly as it does now. So you always
construct a four-byte header datum. Then in heap_form*tuple we check if you
can use a shorter header and convert. VARDATA/VARSIZE would be for looking at
existing datums and would interpret the header bits.
This seems very fragile since one stray call site using VARATT_DATA to find
the data in an existing datum would cause random bugs that only occur rarely
in certain circumstances. It would even work as long as the size is filled in
with VARATT_SIZEP first which it usually is, but fail if someone changes the
order of the statements.
or
b) throw away VARATT_DATA and VARATT_SIZEP and make all user function
everywhere change over to a new macro api. That seems like a pretty big
burden. It's safer but means every contrib module would have to be updated and
so on.
I'm hoping I'm missing something and there's a way to do this without breaking
the api for every user function.
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2007-02-09 03:35:52 | Re: patch adding new regexp functions |
Previous Message | Jeremy Drake | 2007-02-09 03:22:58 | patch adding new regexp functions |