Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
От | Japin Li |
---|---|
Тема | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption |
Дата | |
Msg-id | ME3P282MB3166C4A319DE4263025F4CA5B6FC2@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
|
Список | pgsql-bugs |
On Fri, 31 May 2024 at 16:22, Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > 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! > Thanks for the rewording! LGTM. -- Regrads, Japin Li
В списке pgsql-bugs по дате отправления: