Re: [HACKERS] pg_catversion builtin function - Mailing list pgsql-hackers

From Jesper Pedersen
Subject Re: [HACKERS] pg_catversion builtin function
Date
Msg-id 3a218777-d554-9cd6-7216-bdc4ecfb16a8@redhat.com
Whole thread Raw
In response to Re: [HACKERS] pg_catversion builtin function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pg_catversion builtin function  (Robert Haas <robertmhaas@gmail.com>)
List 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





pgsql-hackers by date:

Previous
From: Ildar Musin
Date:
Subject: Re: [HACKERS] Declarative partitioning - another take
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pg_catversion builtin function