On Wed, Dec 14, 2016 at 8:32 AM, Jesper Pedersen
<jesper.peder...@redhat.com> wrote:
> On 12/13/2016 10:33 AM, Tom Lane wrote:
>> Jesper Pedersen <jesper.peder...@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();
(1 row)

Here's the commit:

commit dc7d70ea05deca9dfc6a25043d406b57cc8f6c30
Author: Joe Conway <m...@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 backend functions
    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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to