Le 25/10/2013 18:44, Tom Lane a écrit :
> Hugo Mercier <hugo.mercier@oslandia.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.
>
> Another point here is that there's no good reason to suppose that a
> function should return a flattened value just because it's at the outer
> level of its syntactic expression. For example, if we're doing a plain
> SELECT foo(...) FROM ..., the next thing that will happen with that value
> is it'll be fed to the output function for the datatype. Maybe that
> output function would like to have a non-flat input value, too, to save
> the time of transforming back to that representation. On the other hand,
> if it's a SELECT ... ORDER BY ... and the planner chooses to do the ORDER
> BY with a final sort step, we'll probably have to flatten the value to
> pass it through sorting. (Or possibly not --- perhaps we could just pass
> the toast token through sorting?) There are a lot of considerations here
> and it's really unreasonable to expect that static expression labeling
> will be able to do the right thing every time.
Again, my proposal is very conservative here. It does not expect to
optimize all spots where copies are not necessary. Only at a some level
of function evaluation with ... some assumptions.
>
> 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 ?
--
Hugo Mercier
Oslandia
