Re: Proposal: QUALIFY clause

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Mike Artz <michaeleartz(at)gmail(dot)com>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Proposal: QUALIFY clause
Date: 2025-07-21 14:29:52
Message-ID: CAMsGm5dAYswFz5RkgEu0ZsGbEJjHaJ3QMOMPYHAGUvY_V69rCg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 21 Jul 2025 at 10:19, Mike Artz <michaeleartz(at)gmail(dot)com> wrote:

> Many times I have thought it would be nice if there was a QUALIFY clause
> in Postgres!
>
> Just would like to add that including your list, Teradata, Redshift, SAP
> HANA, HP Vertica, and Trino all support the QUALIFY clause.
>
> Also it seems Postgres would be the first leading RDBMS - meaning like
> traditional, multipurpose RDMBS - to support QUALIFY, which would be pretty
> cool.
>

Is this different from using the window functions in a subquery and then
applying a WHERE clause on the outer query?

SELECT … FROM (SELECT … [including window functions] FROM …) WHERE [stuff
that would be in QUALIFY]

I'll be honest, I'm skeptical that we need another keyword that basically
means “WHERE, but applied at a different point in the query processing”.
I'm not even convinced that HAVING was a good idea (although obviously I
would not propose removal).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-07-21 14:38:57 Re: Horribly slow pg_upgrade performance with many Large Objects
Previous Message Melanie Plageman 2025-07-21 14:28:39 Re: Parallel heap vacuum