From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_get_sequence_data Shows Non-NULL last_value for Freshly Created Sequence |
Date: | 2025-08-21 00:06:13 |
Message-ID: | aKZi9SUOzpP0wGTB@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 20, 2025 at 01:01:52PM -0400, Tom Lane wrote:
> The proposed patch includes a change to pg_dump that I suppose is
> meant to compensate. But I'm not 100% sure that it does so correctly.
> Anyway, given that it's supposed to provide low-level inspection of
> the sequence tuple, I think that it's best not to be too cute.
The patch goes against the original promise of pg_get_sequence_data()
to "blindly" report the contents of the sequence tuple, so as
decisions can be taken in the frontend and not enforced in the
backend, which is what this patch is trying to introduce.
Also, FWIW, the current behavior of the function also matters around
[1], as this makes it easier for my AM callbacks to report what they
want in the result of pg_get_sequence_data().
[1]: https://commitfest.postgresql.org/55/
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-08-21 00:11:17 | Re: Remove redundant assignment of a variable in function AlterPublicationTables |
Previous Message | Peter Smith | 2025-08-21 00:03:31 | Re: Skipping schema changes in publication |