Re: [HACKERS] pg_catversion builtin function

2016-12-14 Thread Jesper Pedersen
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();

Re: [HACKERS] pg_catversion builtin function

2016-12-14 Thread Robert Haas
On Wed, Dec 14, 2016 at 8:32 AM, Jesper Pedersen wrote: > On 12/13/2016 10:33 AM, Tom Lane wrote: >> Jesper Pedersen writes: >>> Attached is a new builtin function that exposes the CATALOG_VERSION_NO >>> constant under the pg_catversion()

Re: [HACKERS] pg_catversion builtin function

2016-12-14 Thread Jesper Pedersen
On 12/13/2016 10:33 AM, Tom Lane wrote: Jesper Pedersen 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

Re: [HACKERS] pg_catversion builtin function

2016-12-13 Thread Tom Lane
Jesper Pedersen 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

[HACKERS] pg_catversion builtin function

2016-12-13 Thread Jesper Pedersen
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