| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Removing log_cnt from pg_sequence_read_tuple() |
| Date: | 2024-08-29 01:28:03 |
| Message-ID: | Zs_Oo2MPCTL1S3mr@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 29, 2024 at 08:00:52AM +0900, Michael Paquier wrote:
> On Mon, Aug 26, 2024 at 09:19:06AM -0500, Nathan Bossart wrote:
>> The patch looks reasonable to me. Do you think the name of the function
>> still makes sense now that 1) we might have different sequence AMs in the
>> near future and 2) it no longer returns everything in the sequence tuple?
>
> Indeed, pg_sequence_read_tuple() would not reflect the reality, some
> ideas:
> - pg_sequence_read_data
> - pg_sequence_get_data
> - pg_sequence_data
> - More consistent with other catalog functions: pg_get_sequence_data,
> as we have already in the tree a lot of pg_get_* functions.
pg_get_sequence_data() sounds fine to me.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2024-08-29 01:54:57 | Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. |
| Previous Message | Thomas Munro | 2024-08-29 01:22:16 | Re: macOS prefetching support |