Re: FETCH FIRST clause WITH TIES option
От | Alvaro Herrera from 2ndQuadrant |
---|---|
Тема | Re: FETCH FIRST clause WITH TIES option |
Дата | |
Msg-id | 20190905225158.GA30717@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: FETCH FIRST clause WITH TIES option (Surafel Temesgen <surafel3000@gmail.com>) |
Ответы |
Re: FETCH FIRST clause WITH TIES option
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: