Re: pg_catversion builtin function

On Wed, Dec 14, 2016 at 8:32 AM, Jesper Pedersen
<jesper(dot)pedersen(at)redhat(dot)com> wrote:
> On 12/13/2016 10:33 AM, Tom Lane wrote:
>> Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)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(at)joeconway(dot)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