On 2025-Jul-22, Andrew Dunstan wrote:
> If we were making up our own syntax this would be a sensible thing to
> debate. If we're talking about implementing something we expect to be in the
> standard, I think we will have to live with what the standards committee
> decides, regardless of our prefe
On Wed, 23 Jul 2025 at 09:21, Vik Fearing wrote:
> I took a quick look at the patch (without applying and testing it) and
> it seems to me that parse analysis is the wrong place to do this. We
> want ruleutils to be able to spew out the QUALIFY clause as written in a
> view and not as transformed.
On 22/07/2025 20:54, Matheus Alcantara wrote:
(this happens on transformQualifyClause() if you want to take a look)
I took a quick look at the patch (without applying and testing it) and
it seems to me that parse analysis is the wrong place to do this. We
want ruleutils to be able to spew
On Tue Jul 22, 2025 at 3:11 PM -03, Marcos Pegoraro wrote:
> Em ter., 22 de jul. de 2025 às 08:56, Matheus Alcantara <
> matheusssil...@gmail.com> escreveu:
>
>> The current patch supports the following syntaxes:
>> SELECT a, b, c
>> wf() OVER () as d
>> FROM tab
>> QUALIFY d = 1
>>
Em ter., 22 de jul. de 2025 às 08:56, Matheus Alcantara <
matheusssil...@gmail.com> escreveu:
> The current patch supports the following syntaxes:
> SELECT a, b, c
> wf() OVER () as d
> FROM tab
> QUALIFY d = 1
> When using the "QUALIFY d = 1" form, I currently rewrite the expressi
On 2025-07-22 Tu 11:14 AM, Vik Fearing wrote:
I agree that its own clause is best; I just greatly dislike QUALIFY.
Sorry.
If we were making up our own syntax this would be a sensible thing to
debate. If we're talking about implementing something we expect to be in
the standard, I thi
On 22/07/2025 17:14, Nico Williams wrote:
It doesn't seem too crazy that extra WHEREs in WHERE clauses should some
day function as ANDs, and ditto HAVINGs, which is another reason not to
reuse HAVING for this: just to leave that a possibility, remote though
it might be.
I have a firm finger o
On 22/07/2025 17:07, Nico Williams wrote:
On Tue, Jul 22, 2025 at 01:14:20AM -0400, Tom Lane wrote:
Nico Williams writes:
On Mon, Jul 21, 2025 at 09:43:15PM -0600, Merlin Moncure wrote:
Hm, HAVING requires to apply 'group by' which windows functions do not
require (unlike aggregates).
Pave
I often accidentally write
SELECT .. WHERE .. WHERE ..;
which is obviously wrong, but what I mean when I do this is
SELECT .. WHERE .. AND ..;
and if I wrote GROUP BY .. HAVING queries as often as I do ones that
don't GROUP BY then I'd probably also accidentally use extra HAVINGs as
ANDs.
On Tue, Jul 22, 2025 at 01:14:20AM -0400, Tom Lane wrote:
> Nico Williams writes:
> > On Mon, Jul 21, 2025 at 09:43:15PM -0600, Merlin Moncure wrote:
> >> Hm, HAVING requires to apply 'group by' which windows functions do not
> >> require (unlike aggregates).
>
> > Pavel's point is precisely to a
On Mon, Jul 21, 2025 at 11:02:36PM -0600, Merlin Moncure wrote:
> On Mon, Jul 21, 2025 at 10:08 PM Nico Williams
> wrote:
> > I would have a HAVING clause that comes _before_ GROUP BY apply to
> > window functions and a second one that comes _after_ GROUP BY apply to
> > the grouping.
>
> I don't
On Mon Jul 21, 2025 at 7:11 PM -03, Vik Fearing wrote:
> That is my preferred grammar, thank you.
>
Thanks for confirming!
> 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 rewritt
Nico Williams writes:
> On Mon, Jul 21, 2025 at 09:43:15PM -0600, Merlin Moncure wrote:
>> Hm, HAVING requires to apply 'group by' which windows functions do not
>> require (unlike aggregates).
> Pavel's point is precisely to allow HAVING w/o a GROUP BY when there are
> window functions since win
On Mon, Jul 21, 2025 at 10:08 PM Nico Williams
wrote:
> On Mon, Jul 21, 2025 at 09:43:15PM -0600, Merlin Moncure wrote:
> > On Mon, Jul 21, 2025 at 9:19 PM Pavel Stehule
> > wrote:
> > > just for curiosity - why the HAVING clause was not used?
> > >
> > > Any window functions are +/- an "aggrega
On Mon, Jul 21, 2025 at 09:43:15PM -0600, Merlin Moncure wrote:
> On Mon, Jul 21, 2025 at 9:19 PM Pavel Stehule
> wrote:
> > just for curiosity - why the HAVING clause was not used?
> >
> > Any window functions are +/- an "aggregate" function, and then HAVING
> > looks more natural to me.
>
> Hm,
On Mon, Jul 21, 2025 at 9:19 PM Pavel Stehule
wrote:
>
> just for curiosity - why the HAVING clause was not used?
>
> Any window functions are +/- an "aggregate" function, and then HAVING
> looks more natural to me.
>
Hm, HAVING requires to apply 'group by' which windows functions do not
require
Hi
út 22. 7. 2025 v 0:12 odesílatel Vik Fearing
napsal:
>
> 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 fo
Vik Fearing writes:
> 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() OV
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
f
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 syn
On Mon, Jul 21, 2025 at 10:26:51PM +0200, Vik Fearing wrote:
> On 21/07/2025 19:30, Tom Lane wrote:
> > * I'm not exactly convinced that the committee would standardize
> > it just like this. For one thing, QUALIFY is not even the right
> > part of speech: it's a verb, and thus more fit to be a pr
On 21/07/2025 19:30, Tom Lane wrote:
"Matheus Alcantara" writes:
You're right — semantically, using QUALIFY is equivalent to wrapping the
query in a subquery and applying a WHERE clause to the result. The main
motivation here is to provide a more ergonomic and readable syntax.
While I underst
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 lo
On 21/07/2025 16:41, Tom Lane wrote:
Isaac Morland writes:
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”.
That was my reaction too. I'm especially skeptical that getting out
front of the SQL
On Mon, Jul 21, 2025 at 9:32 PM Thom Brown wrote:
>> * I'm not exactly convinced that the committee would standardize
>> it just like this. For one thing, QUALIFY is not even the right
>> part of speech: it's a verb, and thus more fit to be a primary
>> statement keyword. What you need here is a
On Mon, 21 Jul 2025, 18:31 Tom Lane, wrote:
> "Matheus Alcantara" writes:
> > You're right — semantically, using QUALIFY is equivalent to wrapping the
> > query in a subquery and applying a WHERE clause to the result. The main
> > motivation here is to provide a more ergonomic and readable synta
"Matheus Alcantara" writes:
> You're right — semantically, using QUALIFY is equivalent to wrapping the
> query in a subquery and applying a WHERE clause to the result. The main
> motivation here is to provide a more ergonomic and readable syntax.
> While I understand the hesitation around introdu
On Mon Jul 21, 2025 at 11:29 AM -03, Isaac Morland wrote:
> 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 ho
Isaac Morland writes:
> 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”.
That was my reaction too. I'm especially skeptical that getting out
front of the SQL standards committee is a good thing to
On Mon, 21 Jul 2025 at 10:19, Mike Artz 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 Pos
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
traditi
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.
The idea for this came from a discussion and suggestion by Peter
Eisentrau
32 matches
Mail list logo
