Обсуждение: [HACKERS] pg_catversion builtin function

Hi Hackers,

Attached is a new builtin function that exposes the CATALOG_VERSION_NO 
constant under the pg_catversion() function, e.g.

test=# SELECT pg_catversion();
  pg_catversion
---------------
      201612121
(1 row)

Although it mostly useful during the development cycle to verify if 
dump/restore is needed; it could have other use-cases.

I'm unsure of the OID assignment rules - feel free to point me towards 
information regarding this.

I'll register this patch with the next CF.

Best regards,
  Jesper

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

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?
        regards, tom lane

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/

Best regards, Jesper

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

On 12/14/2016 08:52 AM, Robert Haas wrote:
>> 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)
>
>

Ah, perfect !

Thanks, Robert

Best regards, Jesper