From: Tom Lane <tgl@sss.pgh.pa.us>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: Regina Obe <lr@pcorp.us>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Date: Wed, 23 Mar 2016 15:15:54 -0400
Message-ID: <15776.1458760554@sss.pgh.pa.us> (raw)
In-Reply-To: <CAKFQuwY3t-p0KiZ3qWxrj4KonJiEVBVcoBc_0rh2EV-5zAuKEQ@mail.gmail.com>
References: <001201d18524$f84c4580$e8e4d080$@pcorp.us>
<9987.1458754648@sss.pgh.pa.us>
<CAKFQuwY3t-p0KiZ3qWxrj4KonJiEVBVcoBc_0rh2EV-5zAuKEQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wednesday, March 23, 2016, Tom Lane <tgl@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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, david.g.johnston@gmail.com, lr@pcorp.us
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
In-Reply-To: <15776.1458760554@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox