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

Reply via email to