Date: Thu, 5 Sep 2019 18:51:58 -0400
From: Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>
To: Surafel Temesgen <surafel3000@gmail.com>
Cc: Erik Rijkers <er@xs4all.nl>, Thomas Munro <thomas.munro@gmail.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	David Steele <david@pgmasters.net>,
	Michael Paquier <michael@paquier.xyz>,
	Robert Haas <robertmhaas@gmail.com>,
	Andrew Gierth <andrew@tao11.riddles.org.uk>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: FETCH FIRST clause WITH TIES option
Message-ID: <20190905225158.GA30717@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CALAY4q9enemJLe4h16Jku9cYwX9UyCMcA4XWWp_UH79anS8=EA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

As Tom just said in the thread for PERCENT, the gram.y changes need a
better representation.  Also, rename EXACT_NUMBER, per that thread.

As far as I can tell, this concerns feature F867.  I think we should
mark that as supported after this patch -- please edit
src/backend/catalog/sql_features.txt.

Earlier in the thread, Tomas Vondra said:

> 3) I'm a bit confused by the initialization added to ExecInitLimit. It
> first gets the tuple descriptor from the limitstate (it should not do so                                                                                                                    
> directly but use ExecGetResultType). But when it creates the extra slot,                                                                                                                    
> it uses ops extracted from the outer plan. That's strange, I guess ...                                                                                                                      
>                                                                                                                                                                                             
> And then it extracts the descriptor from the outer plan and uses it when                                                                                                                    
> calling execTuplesMatchPrepare. But AFAIK it's going to be compared to                                                                                                                      
> the last_slot, which is using a descriptor from the limitstate.                                                                                                                             
>                                                                                                                                                                                             
> IMHO all of this should use descriptor/ops from the outer plan, no? It                                                                                                                      
> probably does not change anything because limit does not project, but it                                                                                                                    
> seems confusing.                                                                                                                                                                            

and you replied:

> agree

... yet this doesn't appear to have resulted in any change in the code,
or I just missed it.  Are you going to update the patch per that?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services