| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: CTE inlining |
| Date: | 2017-04-30 22:00:18 |
| Message-ID: | d3fdf85c-46ae-41fe-8e90-bf4edc5c9e81@2ndquadrant.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/30/2017 09:46 AM, Andres Freund wrote:
> Hi,
>
> On 2017-04-30 13:58:14 +0800, Craig Ringer wrote:
>> We have OFFSET 0 for anyone really depending on it, and at least when you
>> read that you know to go "wtf" and look at the manual, wheras the CTE fence
>> behaviour is invisible and silent.
>
> I don't think that's a good idea. What if you need to prevent inlining
> of something that actually needs an offset? What if the behaviour of
> offset is ever supposed to change? Relying more on that seems to just
> be repeating the mistake around CTEs.
>
I agree with this. But OFFSET 0 would force people to modify the queries
anyway, so why not just introduce a new keyword instead? Something like:
WITH FENCED a (SELECT ...)
But I think something like that was proposed not too long ago, and did
not make it for some reason.
There's a lot of other CTE improvements that would be great. Say, being
able to define indexes on them, but that's really a separate topic.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2017-04-30 22:25:23 | Re: CTE inlining |
| Previous Message | Tomas Vondra | 2017-04-30 21:54:48 | Re: CTE inlining |