Re: Improve explicit cursor handling in pg_stat_statements - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Improve explicit cursor handling in pg_stat_statements
Date
Msg-id CAA5RZ0tcYDnxmR=nhY-fn9G_eNvFNeqzVO=e3GDS8osEo5dAFA@mail.gmail.com
Whole thread Raw
In response to Re: Improve explicit cursor handling in pg_stat_statements  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Improve explicit cursor handling in pg_stat_statements
List 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

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Next
From: Peter Geoghegan
Date:
Subject: Re: strange perf regression with data checksums