Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers