From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | Önder Kalacı <onderkalaci(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption |
Date: | 2024-05-31 07:22:48 |
Message-ID: | CAPmGK17oWR3Fha8ZMPBye2Ymp18PnYS8hsgXvwOAVdhUzkuN1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, May 31, 2024 at 10:12 AM Japin Li <japinli(at)hotmail(dot)com> wrote:
> I think I understand what you mean. We can ensure that the ORDER BY can be
> safely pushed down if we are in add_foreign_final_paths(). The reason the
> FETCH clause cannot be pushed down is only because the remote may not
> support it, right?
Yeah, I think so; for the next person, I would like to propose to
update the comments proposed upthread to something like this:
/*
* If the query uses FETCH FIRST .. WITH TIES, 1) it must have ORDER BY as
* well, which is used to determine which additional rows tie for the last
* place in the result set, and 2) ORDER BY must already have been
* determined to be safe to push down before we get here. So in that case
* the FETCH clause is safe to push down with ORDER BY if the remote
* server is v13 or later; but if not, the remote query will fail entirely
* for lack of support for it. Since we do not currently have a way to do
* a remote-version check (without accessing the remote server), disable
* pushing it for now.
*/
Comments are welcome!
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Muhammad Imtiaz | 2024-05-31 07:40:32 | Re: BUG #18488: Installation of postgis30_13 fails on Rocky 9 |
Previous Message | Daniel Gustafsson | 2024-05-31 07:05:36 | Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning |