From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Regina Obe <lr@pcorp.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Date: Wed, 23 Mar 2016 18:34:08 -0400
Message-ID: <30200.1458772448@sss.pgh.pa.us> (raw)
In-Reply-To: <25750.1458767514@sss.pgh.pa.us>
References: <001201d18524$f84c4580$e8e4d080$@pcorp.us>
<9987.1458754648@sss.pgh.pa.us>
<CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com>
<20160323201856.GR3127@tamriel.snowman.net>
<25750.1458767514@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
I wrote:
> ... I'd love to
> toss the entire SRF-in-tlist feature overboard one of these years,
> both because of semantic issues like these and because a fair amount
> of code and overhead could be ripped out if it were disallowed.
> But I don't know how we get to that --- as Merlin says, there's a
> pretty large amount of application code depending on the feature.
BTW, after further thought I seem to recall some discussion about whether
we could mechanically transform SRF-in-tlist into a LATERAL query.
That is, we could make the rewriter or planner convert
SELECT srf1(...), srf2(...)
FROM ...
WHERE ...
into
SELECT u.s1, u.s2
FROM ..., LATERAL ROWS FROM(srf1(...), srf2(...)) AS u(s1,s2)
WHERE ...
(The SRF invocations might be buried inside expressions, but we'd find
them and convert them anyway. Also, we'd merge textually-identical SRF
invocations into a single ROWS FROM entry to avoid multiple evaluation,
at least for SRFs not marked volatile.) Having done that, the executor's
support for SRFs in general expressions could be removed, a significant
savings.
One problem with this is that it only duplicates the current behavior
in cases where the SRFs all have the same period. But you could argue
that the current behavior in cases where they don't is widely considered
a bug anyway.
A possibly larger problem is that it causes the SRFs to be evaluated
before sorting/ordering/limiting. In view of the discussions that led
up to 9118d03a8, that could be a fatal objection :-(. Maybe we could
get around it with a different transformation, into a two-level query?
The above sketch doesn't really consider what to do with GROUP BY,
ORDER BY, etc, but maybe we could push those down into a sub-select
that becomes the first FROM item.
Anyway, that's food for thought not something that could realistically
happen right now.
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, sfrost@snowman.net, mmoncure@gmail.com, lr@pcorp.us
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
In-Reply-To: <30200.1458772448@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