Andres Freund <and...@2ndquadrant.com> writes:
> On 2013-10-28 14:26:20 -0400, Tom Lane wrote:
>> No; see my upthread comments. I think what we want to do is to have
>> PG_DETOAST_DATUM automatically flatten non-flat datums, and to require
>> functions that can cope with non-flat inputs to use a new argument
>> fetching macro, exactly along the lines of what we did with non-aligned
>> toasted values awhile ago (see PG_GETARG_TEXT_PP and suchlike).
> My problem isn't datatype specific functions doing superflous
> detoasting. If it were just them, I'd be perfectly happy going your way.
> My concern is type-independent code detoasting everything without giving
> the type specific code any say over it. Like, printtup.c, spi.c,
> rowtype.c...
In all those cases, if we're detoasting at all then there is probably good
reason to flatten as well. Or if not, we'll teach the code the
difference. Just as with function arguments, it can never be *wrong* to
flatten, it might only be inefficient --- so we'll improve the
inefficiencies. One at a time.
>> If we do what you're suggesting here, any attempt to de-flatten a datatype
>> will be a flag day on which *every* *single* *function* that deals with
>> that datatype has to change simultaneously.
> I don't think this is a change on the same scale as V1 call conventions
> or short varlenas which are type independent because a type explicitly
> has to sign up for it.
I think it's going to be more widely adopted than you think, unless we
make it so impractical to adopt that only one or two types ever do it.
> E.g. the numeric storage is private to numeric.c, so it'd be perfectly
> fine to change the numeric representation in a flag day manner as long
> as we still can read the old representation.
So in other words, you believe there is no extension anywhere that deals
with numeric values? Sorry, I don't believe that. And even if I believed
it for numeric, the assumption certainly falls to the ground once you
extend it to every datatype that might have use for this facility.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
