Re: Detection of nested function calls

Hugo Mercier <hugo(dot)mercier(at)oslandia(dot)com> writes:
> Le 25/10/2013 16:18, Tom Lane a crit :
>> However, this seems like a completely wrong way to go at it. In the first
>> place, it wouldn't help for situations like a complex value stored in a
>> plpgsql variable. In the second, I don't think that what you are
>> describing scales to any more than the most trivial situations. What
>> about functions with more than one complex-type input, for example? And
>> you'd need to be certain that every single function taking or returning
>> the datatype gets updated at exactly the same time, else it'll break.

> About functions with more than one complex-type input, as soon as each
> parameter are of the same type, there is no problem with that.

How do you tell the difference between

foo(col1, bar(col2))
foo(bar(col1), col2)

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

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.

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

regards, tom lane