Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-10-28 13:41:46 -0400, Tom Lane wrote:
>> I don't think that's a safe assumption at all. We need to be able to do
>> flattening anywhere PG_DETOAST_DATUM() can be called.
> I am not sure we want things to work along those lines. I'd rather make
> PG_DETOAST_DATUM pass along such in-memory Datums unchanged and require
> any funtion that wants to poke into into the Datum in detail to know
> about the different representations.
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). That way,
code that hasn't yet been updated to deal with non-flat datums will still
work, if a bit inefficiently compared to what we'd like.
Non-performance-critical functions might never get updated at all.
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. That will basically destroy
our chance of ever doing anything about widely-used types like arrays.
This feature *must* be something that we can install support for
incrementally (ie one function at a time), the same way we did with
non-aligned toasted values, or for that matter with several previous
global changes like the adoption of V1 call convention.
> That will require a bit more
> widespread changes in functions using those types natively, but it will
> make it more realistic to use the optimization across much of the code
> that detoasts Datums generally.
You've got that exactly backward; if it's a source code flag day it will
never happen at all. We need to change code when it gets updated to
handle the case, not run around and try to find every function we're not
updating.
regards, tom lane