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

Le 25/10/2013 17:20, Tom Lane a écrit :
> Hugo Mercier <hugo.mercier@oslandia.com> writes:
>> Le 25/10/2013 16:18, 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.

In bar(), you would have the choice to return either a plain A
or a pointer to A. Because bar() knows its call is nested (by foo()),
than it can decide to return a pointer to A.

foo() is then evaluated and we assume it knows A can be a pointer.
foo() then knows its nesting level of 0 and must return something
serialized in that case.

>> I don't understand what you mean by "be certain that every single
>> function ... gets updated at exactly the same time". Could you develop ?
>
> If you're tying this to the syntax of the expression, then bar() *must*
> return a non-serialized value when and only when foo() is expecting that,
> therefore their implementations must change at the same time.  Perhaps
> that's workable for PostGIS, but it's a complete nonstarter for
> widely-known datatypes like arrays, where affected functions might be
> spread through any number of extensions.  We need a design that permits
> incremental fixing of functions that work with a deserializable datatype.

Yes.
It could work for each user type assuming each function working with
this type is aware of this pointer/serialized nature, including extensions.
So you have to, at least, recompile every extensions depending on that
types. Which ... limits the interest for very general types, I have to
admit.

>
> Another point worth worrying about is that not all expressions are
> function calls, nor do all function calls arise from expressions.
> Chasing down all the corner cases and making sure they work properly
> in a syntax-driven approach is going to be a headache.

We could add this 'nesting' detection to operators (and probably other
constructs that I don't know) little by little.
Optimizing only function calls as a first step is not enough ?

>
>> Basically, the 'geometry' type of PostGIS is here extended with a flag
>> saying if the data is actual 'flat' data or a plain pointer. And if this
>> is a pointer, a type identifier is stored.
>
> If you're doing that, why do you need the decoration on the FuncExpr
> expressions?  Can't you just look at your input datums and see if they're
> flat or not?
>

If a function returns a pointer whatever the nesting level is, you could
end with something storing a raw pointer, which is bad. You could
eventually add a way to detect that what you stored was as pointer and
that your data no longer exists (be NULL ?) when read back, but you
basically end with users manipulating pointers, which is bad.

If you want to make it transparent to the user, you need to know the
nesting level to decide whether you could just pass it to something that
is aware of this pointer (nesting level >=1) or serialize it back
(nesting level == 0).

--
Hugo Mercier
Oslandia