Re: Detection of nested function calls

Hugo Mercier <hugo(dot)mercier(at)oslandia(dot)com> writes:
> Le 25/10/2013 18:44, Tom Lane a crit :
>> The point I'm trying to make is that in the first case, foo would be
>> receiving a first argument that was flat and a second that was not flat;
>> while in the second case, it would be receiving a first argument that was
>> not flat and a second that was flat. The expression labeling you're
>> proposing does not help it tell the difference.

> No it does not. It's then up to the data type to store whether it is
> flat or not. And every functions manipulating this type is assumed to be
> aware of this flat/non-flat flagging.

If the data must contain such markers, then what do you need the proposed
expression labeling for? It's awkward and ultimately insufficient.

What you do need, as Andres is saying, is a datatype-specific function
that will re-flatten a non-flat Datum; and the core code has to be aware
to call this when preparing data to be stored on disk. Once you have
that, every C function returning this datatype can make its own choice
of whether to return a flat or non-flat value. Probably the bias would be
towards the latter choice, but there might be cases where it's easier to
return a flattened value. The important point here is that it's a whole
lot easier all around if the choice is made on-the-fly at runtime, rather
than trying to determine what will happen at parse time.

> What I've understood so far is that there is room for new flags in the
> TOAST mechanism, so the idea would be to add a new strategy where opaque
> pointers could be stored. And it would then require a way for extensions
> to register their own "(de)toasting" functions, right ?

The idea I'm thinking about at the moment is that toast tokens of this
sort might each contain a function pointer to the required flattening
function. This avoids an expensive catalog lookup when flattening is
needed. We'd never accept such a thing for data destined for disk;
but since the whole point here is that such data lives only in memory,
I can't see anything wrong with including a function pointer in it.

regards, tom lane