Robert Haas <robertmhaas@gmail.com> writes:
> So I'm not sure what the right thing to do here is.
Andres' points about composite vs noncomposite function result types
seem pretty compelling: we could make the behavior better for scalar
results, but if it then diverges from what happens for composite
results, I don't think that's a step forward.
In the end, no matter how much work we put in, there are going to be some
corner cases that act differently from before. Considering that none of
the previous corner-case behavior here was particularly carefully thought
through, that's not necessarily disastrous. We should also consider that
contorting the logic to be bug-compatible with prior behavior may preclude
additional optimization work in future.
I'm a bit inclined to agree with the idea of explicitly requiring SRFs
in FROM to appear only at the top level of the expression. That was
certainly the only case that the old code was really designed to support,
and I doubt that the documentation claims that it works otherwise. Also,
to the extent that that ensures we give a clear error rather than possibly
giving results that differ from pre-v10, it's probably going to be less
of a foot-gun for users.
In any case we'd have some documentation work to do here. Maybe we should
first look at what, if anything, the docs currently say in this area, and
how they'd need to be adjusted if we stick with the currently-implemented
behavior. As Andres noted, some of the code comments need work too.
regards, tom lane