On Wed, Dec 14, 2016 at 8:32 AM, Jesper Pedersen
<jesper.pedersen@redhat.com> wrote:
> On 12/13/2016 10:33 AM, Tom Lane wrote:
>> Jesper Pedersen <jesper.pedersen@redhat.com> writes:
>>> Attached is a new builtin function that exposes the CATALOG_VERSION_NO
>>> constant under the pg_catversion() function, e.g.
>>
>> I'm pretty sure that we intentionally didn't expose that, reasoning that
>> users should only care about the user-visible version number. What
>> exactly is the argument for exposing this?
>
> I'm using it to get the catalog version from a running instance in order to
> figure out if a dump/restore is needed for the next daily build -- instead
> of keeping the catversion.h file around for each installation, with script
> magic.
>
> Test databases are external to PostgreSQL's test suite, and one is quite
> big, so "cp" is faster than dump/restore :)
>
> But I understand your concern, so "Rejected" is ok under
>
> https://commitfest.postgresql.org/12/906/
I have a better reason for rejecting this patch: we already have this feature.
rhaas=# select catalog_version_no from pg_control_system();catalog_version_no
-------------------- 201612081
(1 row)
Here's the commit:
commit dc7d70ea05deca9dfc6a25043d406b57cc8f6c30
Author: Joe Conway <mail@joeconway.com>
Date: Sat Mar 5 11:10:19 2016 -0800
Expose control file data via SQL accessible functions.
Add four new SQL accessible functions: pg_control_system(), pg_control_checkpoint(), pg_control_recovery(), and
pg_control_init() which expose a subset of the control file data.
Along the way move the code to read and validate the control file to src/common, where it can be shared by the new
backendfunctions and the original pg_controldata frontend program.
Patch by me, significant input, testing, and review by Michael Paquier.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company