| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Rowley <drowley(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org, Richard Guo <guofenglinux(at)gmail(dot)com> |
| Subject: | Re: pgsql: Fix LATERAL join test in test memoize.sql |
| Date: | 2023-01-24 00:08:01 |
| Message-ID: | CAApHDvruLvSdzmP2JE=LsfXcD3mH-m1dv81Vc8tNCWmmO82Z5A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On Tue, 24 Jan 2023 at 12:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hmmm ... we have an agreed syntax for a subquery optimization fence,
> and that ain't it. I wouldn't count on this not breaking again in
> the future. Why not OFFSET 0, which is the usual method?
You're right that OFFSET 0 would have been a better choice. I just
wasn't aware that we were considering changing the code so we pull up
subqueries with an ORDER BY. In fact, I thought there were several
good reasons we're not doing that. e.g. allow aggregation in outer
query by some order specified by the subquery. But perhaps any changes
we make in this area would be more conditional than just ignoring the
fact that the subquery has an ORDER BY.
In any case, I agree that OFFSET 0 is a better choice, so I'll go and edit that.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-01-24 00:23:08 | Re: pgsql: Fix LATERAL join test in test memoize.sql |
| Previous Message | Tom Lane | 2023-01-23 23:37:41 | Re: pgsql: Fix LATERAL join test in test memoize.sql |