Re: Detection of nested function calls

On 2013-10-28 09:13:06 +0100, Hugo Mercier wrote:
> Le 25/10/2013 18:44, Tom Lane a écrit :
> > Hugo Mercier <hugo(dot)mercier(at)oslandia(dot)com> writes:
> >> Le 25/10/2013 17:20, Tom Lane a écrit :
> >>> How do you tell the difference between
> >>>
> >>> foo(col1, bar(col2))
> >>> foo(bar(col1), col2)
> >
> >> Still not sure to understand ...
> >> I assume foo() takes two argument of type A.
> >> bar() can take one argument of A or another type B.
> >
> > I was assuming everything was the same datatype in this example, ie
> > col1, col2, and the result of bar() are all type A.
> >
> > 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.

But what if the in-memory type contains pointers and is copied or
spilled to disk? There needs to be a mechanism handling that case.

> > Basically the only way to make this work reliably is for Datums to be
> > self-identifying as to whether they're flat or structured values; then
> > make code do the right thing on-the-fly at runtime depending on what kind
> > of Datum it gets. Once you've done that, I don't see that parse-time
> > labeling of expression nesting adds anything useful. As Andres said,
> > the provisions for toasted datums are a good precedent, and none of that
> > depends on parse-time decisions.
> >
>
> This is something I have to investigate, thanks for pointing it out.
> 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 ?

I think we'd need another argument to CREATE FUNCTION like SERIALIZE
pointing to a function that that has to return data that can be stored
on disk. Deserialization would be up to individual functions.

Depending on the specification this might turn out to be slightly
invasive, tuplestore/sort et al probably have to care...

Greetings,

Andres Freund

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