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 |
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 ? |