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.
Reading Tom's response, I think he is right, it sounds simpler & better to
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