Re: Proposal: QUALIFY clause

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Proposal: QUALIFY clause
Date: 2025-07-21 22:11:59
Message-ID: 6c998e4f-f6f2-43c2-8b67-cfff360ef241@postgresfriends.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 21/07/2025 23:29, Matheus Alcantara wrote:
> On Mon Jul 21, 2025 at 5:23 PM -03, Vik Fearing wrote:
>> On 21/07/2025 14:47, Matheus Alcantara wrote:
>>> Hi all,
>>>
>>> I'm sending a proof-of-concept patch to add support for the QUALIFY
>>> clause in Postgres. This feature allows filtering rows after window
>>> functions are computed, using a syntax similar to the WHERE or HAVING
>>> clauses.
>>
>> I took a very brief look at this, and I think your grammar is wrong.
>> The QUALIFY clause should go after the WINDOW clause, just like
>> FROM/WHERE and GROUP BY/HAVING.
>>
>>
>> That is what I am proposing to the standards committee, and I already
>> have some buy-in for that.
>>
> Thank you for the brief review and for the comments!
>
> I'm not sure if I fully understand but please see the new attached
> version.

That is my preferred grammar, thank you.  I have not looked at the C
code by this can be obtained with a syntax transformation. To wit:

SELECT a, b, c
FROM tab
QUALIFY wf() OVER () = ?

can be rewritten as:

SELECT a, b, c
FROM (
    SELECT a, b, c, wf() OVER () = ? AS qc
    FROM tab
) AS q
WHERE qc

and then let the optimizer take over.  The standard does this kind of
thing all over the place; I don't know what the postgres project's
position on doing things like this are.

--

Vik Fearing

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2025-07-21 22:17:13 Re: [PATCH] Proposal to Enable/Disable Index using ALTER INDEX
Previous Message Sami Imseih 2025-07-21 21:47:31 Re: track generic and custom plans in pg_stat_statements