Re: Detection of nested function calls

2013/10/28 Andres Freund <andres(at)2ndquadrant(dot)com>

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

Then you need a functions than prepare a clone of unpacked data too.

Regards

Pavel

>
> Greetings,
>
> Andres Freund
>
> --
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>