Re: FETCH FIRST clause WITH TIES option - Mailing list pgsql-hackers
From | Alvaro Herrera |
---|---|
Subject | Re: FETCH FIRST clause WITH TIES option |
Date | |
Msg-id | 20191111145649.GA7829@alvherre.pgsql Whole thread Raw |
In response to | Re: FETCH FIRST clause WITH TIES option (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Responses |
Re: FETCH FIRST clause WITH TIES option
(Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: FETCH FIRST clause WITH TIES option (Surafel Temesgen <surafel3000@gmail.com>) Re: FETCH FIRST clause WITH TIES option (Alvaro Herrera <alvherre@2ndquadrant.com>) Re: FETCH FIRST clause WITH TIES option (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
List | pgsql-hackers |
Looking at this patch again. (Attached v13 fixes a typo in ruleutils, fixes a bogus edit in the SGML docs plus minor rewording, and is rebased to current master). First, I noticed that there's a significant unanswered issue from Andrew Gierth about this using a completely different mechanism, namely an implicit window function. I see that Robert was concerned about the performance of Andrew's proposed approach, but I don't see any reply from Surafel on the whole issue. Andrew: Would you rather not have this feature in this form at all? Tomas, are you still intending to be committer for this? There's also this point that was not discussed very much: On 2018-Oct-28, Tomas Vondra wrote: > One question is whether to make this work for LIMIT too, not just for > FETCH FIRST. I'm not sure how difficult would that be (it should be a > grammar-only tweak I guess), or if it's a good idea in general. I was also thinking that it would be good to support the new clause under the LIMIT spelling, but it turns out that there are shift/reduce conflicts if done the naive way(*); fixing those looks to be rather major surgery to the way we represent the LIMIT/OFFSET clauses. I'm not sure the proposed changes to gram.y are all that great, though. Right now we have separate productions offset_clause and limit_clause, and a combination mechanism called select_limit; after the patch the whole thing is a little bit too messy. Would it be sensible to unify/ rationalize these? (*) this: diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y index 72ad633102..01d337c30e 100644 --- a/src/backend/parser/gram.y +++ b/src/backend/parser/gram.y @@ -11672,6 +11672,13 @@ limit_clause: n->limitOption = LIMIT_OPTION_COUNT; $$ = n; } + | LIMIT select_limit_value WITH TIES + { + LimitClause *n = (LimitClause *) palloc(sizeof(LimitClause)); + n->limitCount = $2; + n->limitOption = LIMIT_OPTION_WITH_TIES; + $$ = n; + } | LIMIT select_limit_value ',' select_offset_value { /* Disabled because it was too confusing, bjm 2002-02-18 */ -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
pgsql-hackers by date: