Re: Analytic Function Bug - Mailing list pgsql-general

From Rumpi Gravenstein
Subject Re: Analytic Function Bug
Date
Msg-id CAEpg1wAyaMmYYgCLm1Ohft50SCiuhgMRRr0u880wAkyFxpbs6w@mail.gmail.com
Whole thread Raw
In response to Re: Analytic Function Bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Analytic Function Bug
List pgsql-general
<snip>
that the lag() functions are seeing some rows that don't show up in
the final output.  
</snip>

I'm under the impression that the predicate filter is applied before the analytic is evaluated.  Are you suggesting that I have this wrong -- the analytic is evaluated and then the filter is applied?

On Thu, Aug 29, 2024 at 8:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rumpi Gravenstein <rgravens@gmail.com> writes:
> Is this a PostgreSQL bug?

Maybe, but you haven't provided enough information to let anyone else
reproduce the behavior.

Personally I'm suspicious that because your lag() calls are over

    partition by p.logical_partition_key, p.txt order by indx

but then you filter by

    where logical_partition_key='TEST_DATA' and usage_text='F(T61)(EXPORT)';

that the lag() functions are seeing some rows that don't show up in
the final output.  (This'd require that some output rows from "parse"
share txt values but not usage_text values, but that certainly looks
like it's possible.)  So IMO you have not actually demonstrated that
there is any bug.

                        regards, tom lane


--
Rumpi Gravenstein

pgsql-general by date:

Previous
From: Muhammad Usman Khan
Date:
Subject: Re: default privileges are npt working
Next
From: Rumpi Gravenstein
Date:
Subject: Re: Analytic Function Bug