Re: Improve explicit cursor handling in pg_stat_statements

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improve explicit cursor handling in pg_stat_statements
Date: 2025-06-04 16:51:56
Message-ID: CAA5RZ0tcYDnxmR=nhY-fn9G_eNvFNeqzVO=e3GDS8osEo5dAFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hmm. I was not sure if we'd really need to get down to that, as most
> of the grammar keywords have the same parsed meaning, but there's a
> good point with LAST for example that uses a negative value for
> howMany. If we silence the number, LAST would map with everything
> else that has FETCH_ABSOLUTE. That would be confusing.

yes, that is another good case. I think distinguishing between the
various keywords makes the most sense.

> > I considered introducing an enum for these explicit direction values, but
> > didn’t find it particularly useful. If you think it would be beneficial,
> > I can define an enum in parsenodes.h
>
> An enum would shine here IMO, because the value could be
> self-documented and one would not need to guess what each integer
> value means. That could be something like a direction_keyword, filled
> with FETCH_KEYWORD_LAST, FETCH_KEYWORD_BACKWARD, etc.

Done in v4.

--
Sami

Attachment Content-Type Size
v4-0001-Normalize-variable-fetch-sizes-in-a-FETCH-command.patch application/octet-stream 14.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2025-06-04 17:39:40 Re: strange perf regression with data checksums
Previous Message Nathan Bossart 2025-06-04 16:19:28 Re: like pg_shmem_allocations, but fine-grained for DSM registry ?