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