From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rumpi Gravenstein <rgravens@gmail.com>
cc: PostgreSQL <pgsql-general@lists.postgresql.org>
Subject: Re: Analytic Function Bug
In-reply-to: <CAEpg1wDJU6DzUJxJdFAUZFzmw6bY+p17bXvCLupwsxc0V6vqrg@mail.gmail.com>
References: <CAEpg1wDJU6DzUJxJdFAUZFzmw6bY+p17bXvCLupwsxc0V6vqrg@mail.gmail.com>
Comments: In-reply-to Rumpi Gravenstein <rgravens@gmail.com>
	message dated "Thu, 29 Aug 2024 19:18:16 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <317219.1724976433.1@sss.pgh.pa.us>
Date: Thu, 29 Aug 2024 20:07:13 -0400
Message-ID: <317220.1724976433@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/317220.1724976433%40sss.pgh.pa.us>
Precedence: bulk

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