From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_catversion builtin function |
Date: | 2016-12-14 13:32:11 |
Message-ID: | 3a218777-d554-9cd6-7216-bdc4ecfb16a8@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
Best regards,
Jesper
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-12-14 13:52:18 | Re: pg_catversion builtin function |
Previous Message | Ildar Musin | 2016-12-14 12:25:15 | Re: Declarative partitioning - another take |