Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption - Mailing list pgsql-bugs

From Etsuro Fujita
Subject Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
Date
Msg-id CAPmGK17oWR3Fha8ZMPBye2Ymp18PnYS8hsgXvwOAVdhUzkuN1A@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption  (Japin Li <japinli@hotmail.com>)
Responses Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
List pgsql-bugs
On Fri, May 31, 2024 at 10:12 AM Japin Li <japinli@hotmail.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



pgsql-bugs by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
Next
From: Muhammad Imtiaz
Date:
Subject: Re: BUG #18488: Installation of postgis30_13 fails on Rocky 9