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-03 18:04:36
Message-ID: CAA5RZ0vFY3bxpWXoZVFgvkm1zka-dcDJ=TZdzuazc2XT6TGF=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hmm, we could do that to differentiate the keyword ALL. I had a thought
> earlier about differentiating the other keywords as well: FIRST, LAST,
> BACKWARD, FORWARD, and ABSOLUTE. Initially, I thought it might
> be a bit too much, but I do see the merit in this approach, as these are
> syntactically different from their numeric counterparts.
>
> We can accomplish this with just an extra field in FetchStmt, where each
> of these keywords gets a distinct value.
>
> What do you think?

v3 is what I'm thinking: In FetchStmt, introduce a new field called
explicit_direction (maybe there's a better name?), which is an int that
we can assign a value to in gram.c. The value will be 0 if no explicit
direction is used. Otherwise, each of the explicit directions (i.e., FIRST,
LAST, BACKWARD) will be assigned a unique value. FORWARD ALL and
BACKWARD ALL will be treated as distinct from FORWARD and BACKWARD.

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

I also slightly reorganized the fetch_args so the like values for
n->explicit_direction are nearby each other. It does not change
the behavior.

Also, modified the tests to match and some additional code comments.

--
Sami Imseih
Amazon Web Services (AWS)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2025-06-03 18:05:10 Re: Correcting freeze conflict horizon calculation
Previous Message Nathan Bossart 2025-06-03 18:01:58 Re: fix notes about password encryption in pg_authid docs