2012/7/30 Tom Lane <t...@sss.pgh.pa.us> > Josh Berkus <j...@agliodbs.com> writes: > >> it looks like row_number is evaluated before SRF - this behave is > >> absolutely undefined - for me - more native behave is different > evaluation. > > > SRFs which return multiple rows in the SELECT clause have ALWAYS behaved > > oddly when it comes to row evaluation (LIMIT, COUNT(), etc.). This > > isn't necessarily desireable, but it is consistent with past releases, > > and it's not in any way limited to Windowing functions. In general, if > > you care about rows when calling such an SRF, you need to subselect it. > > > It would be nice to clean that up, but you'd have to start with a > > comprehensive definition of what the behavior *should* be in all common > > cases. And then you'd be in for a big code overhaul. > > And a lot of application code breakage, if you change the semantics at all. > > My feeling is that SRFs in targetlists are just fundamentally poorly > defined, and the answer is to avoid them not try to make them cleaner. > Most of the real use-cases for tihem could be handled in a > better-defined, more standard way with LATERAL ... so what we ought > to be spending time on is getting LATERAL done, not worrying about > putting lipstick on tlist SRFs. >
I don't propose any changes - I would to show interesting/strange usage of SRF - this is a new use case of old issue - and I agree so we need LATERAL more and early. Regards Pavel > > 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 >
