public inbox for [email protected]  

help / color / mirror / Atom feed

From: Erik Brandsberg <[email protected]>
To: Romain Carl <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Window functions: frame-adhering aggregate without ORDER BY clause
Date: Mon, 26 Jun 2023 12:21:35 -0400
Message-ID: <CAFcck8HWsQadTntZkucu-0rCcukM2=79WJPuM6JHxqngaMT1VA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

I would add to this that tests that ensure that undocumented behaviors are
consistent are a good thing.  I have seen many cases in my life where
changing such behaviors will trigger breakage in applications that
(unfortunately) depend on them.  As such, by having the tests, it ensures
that someone has to make a decision if they are broken, and decide if it is
worth the risk.

On Mon, Jun 26, 2023 at 11:14 AM Romain Carl <[email protected]> wrote:

> Alright, this makes sense. Thank you for the quick response!
>
> Best regards,
> Romain Carl
>
> On 26.06.23 15:54, Tom Lane wrote:
> > Romain Carl <[email protected]> writes:
> >> among the window tests (src/test/regress/expected/window.out), I noticed
> >> the presence of tests that rely upon the order of rows not determined by
> >> any ORDER BY clause, such as:
> > Yeah ...
> >
> >> The current row's frame and, consequently, the result of the sum
> >> aggregate depend on the order produced by the sequential scan of table
> >> tenk1. Since such order is, in general, not part of PG's defined
> >> behavior, what purpose do the tests that rely upon it serve?
> > The tests are perfectly entitled to test PG's actual behavior.
> > I don't see much difference between this particular case and the
> > fact that we have any tests at all that lack ORDER BY, because
> > formally speaking the engine could choose to emit the rows in
> > some other order.  In practice, if we ever did make the engine
> > behave differently, it'd be on us to fix affected test cases.
> >
> >> Following up to that, how is an EXCLUDE GROUP defined to behave in
> >> absence of any ORDER BY clause?
> > I see in the docs
> >
> >      <literal>EXCLUDE GROUP</literal> excludes the current row and its
> >      ordering peers from the frame.
> >
> > and a bit later
> >
> >      Without <literal>ORDER BY</literal>,
> >      ... all rows become peers of the current row.
> >
> > so excluding the whole frame seems like the right behavior.
> >
> >                       regards, tom lane
>
>
>

view thread (4+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Window functions: frame-adhering aggregate without ORDER BY clause
  In-Reply-To: <CAFcck8HWsQadTntZkucu-0rCcukM2=79WJPuM6JHxqngaMT1VA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox