Re: Detection of nested function calls - Mailing list pgsql-hackers

On 2013-10-28 14:26:20 -0400, Tom Lane wrote:
> 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.

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...
I guess we'll have to spread knowledge over the the new toast type to
those places then.

> 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.

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.
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.

I grant you that arrays are *the* counter example to this.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services