"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Wednesday, March 23, 2016, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> ... We've more or less deprecated SRF-in-tlist since we
>> introduced LATERAL in 9.3. How much are we willing to do to stay
>> bug-compatible with old behaviors here?
> My gut reaction is that this is an unnecessary regression for the sake of a
> performance optimization that is likely drowned out in the usage presented
> anyway.
> The pivot for me would be how hard would it be to maintain the old behavior
> in this "more or less deprecated" scenario. I have no way to judge that.
Well, it'd make make_sort_input_target() more complicated and a bit
slower, mainly because it would have to check SRF-ness of sorting columns
that it currently has no need to inspect at all. My concern here is not
really with that, it's with trying to draw a boundary around what behavior
we're going to promise bug-compatibility with. To illustrate, you really
can get the multiple-expansions behavior with existing releases, eg in
9.4
regression=# SELECT (dumpset(f.test, 'hello world' || f.test)).*, f.test
FROM generate_series(1,4) As f(test)
GROUP BY junk2, f.test;
id | junk1 | junk2 | test
----+---------------+-------+------
1 | 3hello world3 | 31 | 3
2 | 3hello world3 | 31 | 3
1 | 4hello world4 | 42 | 4
2 | 4hello world4 | 42 | 4
1 | 4hello world4 | 41 | 4
2 | 4hello world4 | 41 | 4
1 | 1hello world1 | 11 | 1
2 | 1hello world1 | 11 | 1
1 | 3hello world3 | 32 | 3
2 | 3hello world3 | 32 | 3
1 | 2hello world2 | 21 | 2
2 | 2hello world2 | 21 | 2
1 | 2hello world2 | 22 | 2
2 | 2hello world2 | 22 | 2
1 | 1hello world1 | 12 | 1
2 | 1hello world1 | 12 | 1
(16 rows)
which is kind of fun to wrap your head around, but after awhile you
realize that dumpset(...).junk2 is being evaluated before the GROUP BY
and dumpset.(...).id after it, which is how come the grouping behavior
is so obviously violated.
AFAICS, the only way to ensure non-crazy behavior for such examples would
be to force all SRFs in the tlist to be evaluated at the same plan step.
Which we've never done in the past, and if we were to start doing so,
it would cause a behavioral change for examples like this one.
Anyway, my concern is just that we're deciding to stay bug-compatible
with some behaviors that were not very well thought out to start with,
and we don't even have a clear understanding of where the limits of
that compatibility will be.
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
