Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
| От | Önder Kalacı |
|---|---|
| Тема | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption |
| Дата | |
| Msg-id | CACawEhVXt6uBOk+6stLmPgzPJFxXeL4ndrhwbBEYa07vyoxb0w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption (Japin Li <japinli@hotmail.com>) |
| Ответы |
Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
|
| Список | pgsql-bugs |
Hi,
altogether, and that it might be better to refuse to send WITH_TIES
clauses to the remote at all. I think that this approach to a fix might be the wrong thing
I didn't take this into consideration previously.
I think I confused many people with my first bug-report, where I mentioned
about deparser. Sorry about that.
refuse to send WITH_TIES at all. Especially if we consider this as a candidate
for backport to earlier versions. I think supporting pushdown of WITH_TIES
can probably be considered as a new feature, and deserves its own patch &
discussion.
> +SELECT * FROM ft1 t1 ORDER BY t1.c2 FETCH FIRST 2 ROWS WITH TIES;
I think it is excessive that the query returns 100 rows. Can we add few filters, like
a filter (c5 = `Thu Jan 01 00:00:00 1970` AND c3 > '00500') or such that we only have
few rows to show in the output?
+ /*
+ * Also, the FETCH FIRST/NEXT ... ROW/ROWS WITH TIES cannot be pushed down
+ * due to potential lack of support for this clause on the remote.
+ */
Would be nice to mention potential risks due to collation-incompatibilities in this comment.
I feel like that is probably more important than the lack of WITH TIES support. For example,
in a few years, someone might decide to remove this check by assuming that it is only
added as PG 13 would not be officially supported by the community (e.g., end of life).
+ if (parse->limitOption == LIMIT_OPTION_WITH_TIES)
+ return;
+
Other than that, the check you added looks like a reasonable place to add.
Thanks,
Onder
В списке pgsql-bugs по дате отправления: