Subject: Re: [HACKERS] Unsupported feature F867: WITH TIES
To: =?UTF-8?Q?J=c3=bcrgen_Purtz?= <juergen@purtz.de>,
 pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
References: <5ab043b6-686d-b907-6672-7d39738ebd6f@purtz.de>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <6a6214a6-68dc-e828-527c-c0509d9aee92@2ndquadrant.com>
Date: Fri, 26 Aug 2016 11:58:52 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <5ab043b6-686d-b907-6672-7d39738ebd6f@purtz.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

On 8/26/16 9:06 AM, Jürgen Purtz wrote:
> Actually we don't support the SQL feature F867 "FETCH FIRST clause: WITH 
> TIES option". On the other side we support the window function "rank()" 
> which acts like the "WITH TIES option". My questions are: Is it hard to 
> implement the "WITH TIES option"? Are there plans for a realization / 
> how do we decide in general what to do next? Differs the semantic of the 
> "WITH TIES option" significantly from the "rank()" window function or 
> can we treat it as some kind of 'syntactical sugar'?

LIMIT/FETCH FIRST works at a level that is quite far removed from data
type semantics, which is what you'd need to have handy to compute ties.
LIMIT basically just tells the executor to stop after getting a certain
number of rows.

So implementing WITH TIES would be very difficult in the current setup.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql