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
From 39d52f5389bf3ef1814c1f201df6531feb2a5c7f Mon Sep 17 00:00:00 2001
From: jesperpedersen <jesper.pedersen@redhat.com>
Date: Tue, 13 Dec 2016 08:27:18 -0500
Subject: [PATCH] pg_catversion builtin function
---
doc/src/sgml/func.sgml | 6 ++++++
src/backend/utils/adt/version.c | 10 ++++++++++
src/include/catalog/pg_proc.h | 3 +++
src/include/utils/builtins.h | 1 +
4 files changed, 20 insertions(+)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 0f9c9bf..6fc78ab 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -15497,6 +15497,12 @@ SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
<entry><type>text</type></entry>
<entry><productname>PostgreSQL</> version information. See also <xref linkend="guc-server-version-num"> for a machine-readable version.</entry>
</row>
+
+ <row>
+ <entry><literal><function>pg_catversion()</function></literal></entry>
+ <entry><type>int</type></entry>
+ <entry>returns the catalog version number</entry>
+ </row>
</tbody>
</tgroup>
</table>
diff --git a/src/backend/utils/adt/version.c b/src/backend/utils/adt/version.c
index f247992..55f97fa 100644
--- a/src/backend/utils/adt/version.c
+++ b/src/backend/utils/adt/version.c
@@ -14,6 +14,7 @@
#include "postgres.h"
+#include "catalog/catversion.h"
#include "utils/builtins.h"
@@ -22,3 +23,12 @@ pgsql_version(PG_FUNCTION_ARGS)
{
PG_RETURN_TEXT_P(cstring_to_text(PG_VERSION_STR));
}
+
+/*
+ * Return the catalog version number
+ */
+Datum
+pgsql_catversion(PG_FUNCTION_ARGS)
+{
+ PG_RETURN_INT32(CATALOG_VERSION_NO);
+}
diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h
index cd7b909..b23f54a 100644
--- a/src/include/catalog/pg_proc.h
+++ b/src/include/catalog/pg_proc.h
@@ -235,6 +235,9 @@ DATA(insert OID = 1258 ( textcat PGNSP PGUID 12 1 0 0 0 f f f f t f i s 2 0
DATA(insert OID = 84 ( boolne PGNSP PGUID 12 1 0 0 0 f f f t t f i s 2 0 16 "16 16" _null_ _null_ _null_ _null_ _null_ boolne _null_ _null_ _null_ ));
DATA(insert OID = 89 ( version PGNSP PGUID 12 1 0 0 0 f f f f t f s s 0 0 25 "" _null_ _null_ _null_ _null_ _null_ pgsql_version _null_ _null_ _null_ ));
DESCR("PostgreSQL version string");
+DATA(insert OID = 7000 ( pg_catversion PGNSP PGUID 12 1 0 0 0 f f f f t f s s 0 0 23 "" _null_ _null_ _null_ _null_ _null_ pgsql_catversion _null_ _null_ _null_ ));
+DESCR("PostgreSQL catalog version number");
+
DATA(insert OID = 86 ( pg_ddl_command_in PGNSP PGUID 12 1 0 0 0 f f f f t f i s 1 0 32 "2275" _null_ _null_ _null_ _null_ _null_ pg_ddl_command_in _null_ _null_ _null_ ));
DESCR("I/O");
diff --git a/src/include/utils/builtins.h b/src/include/utils/builtins.h
index 7ed1623..83b2846 100644
--- a/src/include/utils/builtins.h
+++ b/src/include/utils/builtins.h
@@ -893,6 +893,7 @@ extern Datum text_format_nv(PG_FUNCTION_ARGS);
/* version.c */
extern Datum pgsql_version(PG_FUNCTION_ARGS);
+extern Datum pgsql_catversion(PG_FUNCTION_ARGS);
/* xid.c */
extern Datum xidin(PG_FUNCTION_ARGS);
--
2.7.4
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