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
Attachments:
0001-pg_catversion-builtin-function_v1.patchtext/x-patch; name=0001-pg_catversion-builtin-function_v1.patchDownload+20-1
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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 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:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/14/2016 08:52 AM, Robert Haas wrote:
But I understand your concern, so "Rejected" is ok under
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers