New Window Function: ROW_NUMBER_DESC() OVER() ? - Mailing list pgsql-hackers

From David G. Johnston
Subject New Window Function: ROW_NUMBER_DESC() OVER() ?
Date
Msg-id CAKFQuwYCK2f_a+d=xa9v+ZTANzPr2RMus2auOu7MEQ1PrNVfwA@mail.gmail.com
Whole thread Raw
In response to RE: New Window Function: ROW_NUMBER_DESC() OVER() ?  (Maiquel Grassi <grassi@hotmail.com.br>)
Responses RE: New Window Function: ROW_NUMBER_DESC() OVER() ?
List pgsql-hackers
On Tuesday, January 16, 2024, Maiquel Grassi <grassi@hotmail.com.br> wrote:
However, initially, I have one more obstacle in your feedback. If I use count(*) over() - row_number() over(), it gives me an offset of one unit. To resolve this, I need to add 1. 

This way, simulating a reverse row_number() becomes even more laborious.

I don’t really understand why you think this reverse inserted counting is even a good idea so I don’t really care how laborious it is to implement with existing off-the-shelf tools.  A window function named “descending” is non-standard and seemingly non-sensical and should not be added.  You can specify order by in the over clause and that is what you should be doing.  Mortgage payments are usually monthly, so order by date.

David J.

--//--

We are just raising hypotheses and discussing healthy possibilities here. This is a suggestion for knowledge and community growth. Note that this is not about a new "feature patch.


That is not how your initial post here came across.  It seemed quite concrete in goal and use case motivating that goal.


I am asking for the community's opinion in general. Your responses are largely appearing aggressive and depreciative. Kindly request you to be more welcoming in your answers and not oppressive. This way, the community progresses more rapidly..


The people in this community are quite capable and willing to write a contrary opinion to mine.  Not sure how to make “this new proposed function shouldn’t be added to core”, and trying to explain why not, non-oppressive.  I can add “thank you for taking the time to try and improve PostgreSQL” in front to soften the blow of rejection but I tend to just get to the point.

David J.

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Next
From: David Rowley
Date:
Subject: Re: Revise the Asserts added to bimapset manipulation functions