Обсуждение: [HACKERS] pg_config --version-num
Hi all Attached is a small patch to teach pg_config how to output a --version-num With Pg 10, parsing versions got more annoying. Especially with "10beta1", "9.6beta2" etc into the mix. It makes no sense to force tools and scripts to do this when we can just expose a sensible pre-formatted one at no cost to us. Personally I'd like to backpatch this into supported back branches, but just having it in pg 10 would be a help. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote: > Attached is a small patch to teach pg_config how to output a --version-num > > With Pg 10, parsing versions got more annoying. Especially with > "10beta1", "9.6beta2" etc into the mix. It makes no sense to force > tools and scripts to do this when we can just expose a sensible > pre-formatted one at no cost to us. > > Personally I'd like to backpatch this into supported back branches, > but just having it in pg 10 would be a help. The last threads treating about the same subject are here: https://www.postgresql.org/message-id/CAB7nPqTAdAJpX8iK4V3uYJbO2Kmo8rHzqJKDsLaDdranNrGX_A@mail.gmail.com https://www.postgresql.org/message-id/20161127001648.GA21874@fetter.org Is the data in Makefile.global unsufficient? -- Michael
On 31 May 2017 9:36 am, "Michael Paquier" <michael.paquier@gmail.com> wrote:
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote:The last threads treating about the same subject are here:
> Attached is a small patch to teach pg_config how to output a --version-num
>
> With Pg 10, parsing versions got more annoying. Especially with
> "10beta1", "9.6beta2" etc into the mix. It makes no sense to force
> tools and scripts to do this when we can just expose a sensible
> pre-formatted one at no cost to us.
>
> Personally I'd like to backpatch this into supported back branches,
> but just having it in pg 10 would be a help.
https://www.postgresql.org/message-id/ CAB7nPqTAdAJpX8iK4V3uYJbO2Kmo8 rHzqJKDsLaDdranNrGX_A@mail. gmail.com
https://www.postgresql.org/message-id/20161127001648. GA21874@fetter.org
Is the data in Makefile.global unsufficient?
It's a pain in the butt because then you need to find or get passed the name of Makefile.global. Then you have to template it out into a file. Or parse the Makefile. Or create a wrapper program to emit it.
It's beyond me why we don't expose this at runtime for use in scripts and tools. (Then again, the same is true of reporting it in the startup message and we know how that's gone).
Craig Ringer <craig@2ndquadrant.com> writes:
> On 31 May 2017 9:36 am, "Michael Paquier" <michael.paquier@gmail.com> wrote:
>> Is the data in Makefile.global unsufficient?
> It's a pain in the butt because then you need to find or get passed the
> name of Makefile.global. Then you have to template it out into a file. Or
> parse the Makefile. Or create a wrapper program to emit it.
> It's beyond me why we don't expose this at runtime for use in scripts and
> tools. (Then again, the same is true of reporting it in the startup message
> and we know how that's gone).
Hm, but with this you're trading that problem for "is the right version
of pg_config in my PATH?". I can't see using this in TAP testing, for
instance, because it would never work in "make check" scenarios.
This idea might well be useful for external packages which are always
built/tested against installed versions of Postgres. But it seems like
we need to think harder about what to do for our own usages, and that
may lead to a different solution altogether.
regards, tom lane
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> Attached is a small patch to teach pg_config how to output a --version-num
>
> With Pg 10, parsing versions got more annoying. Especially with
> "10beta1", "9.6beta2" etc into the mix. It makes no sense to force
> tools and scripts to do this when we can just expose a sensible
> pre-formatted one at no cost to us.
>
> Personally I'd like to backpatch this into supported back branches,
> but just having it in pg 10 would be a help.
The last threads treating about the same subject are here:
https://www.postgresql.org/message-id/ CAB7nPqTAdAJpX8iK4V3uYJbO2Kmo8 rHzqJKDsLaDdranNrGX_A@mail. gmail.com
Tom's comment here:
"whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda)."
The proposed doesn't touch the first item and patch author's aren't expected to handle the second. Not sure what all the rest entails...but I cannot imagine it is a considerable amount of stuff that amounts to little more than boilerplate text paralleling what is already out there for the existing --version option. If someone is willing to do that I'd think we should feel OK with the little bit of translation would that would need to occur because of it.
The fact that this is even on the radar means that more than likely there are sensible uses for this capability whether they've been adequately presented or not. We don't have someone begging for help here but rather ultimately a complete patch that can be committed and which would require pretty much zero maintenance.
While I don't do it presently I could very well imagine value in being able to inspect installed versions PostgreSQL, including patch levels, without needing a running server process or the ability to login.
David J.
Hm, but with this you're trading that problem for "is the right version
of pg_config in my PATH?".
That is probably a solved problem for those who are parsing the output of --version today.
This idea might well be useful for external packages which are always
built/tested against installed versions of Postgres. But it seems like
we need to think harder about what to do for our own usages, and that
may lead to a different solution altogether.
While we may not want to go to the extreme that is Perl, there being more than one way to do things does have merit. Given that we run 5 concurrent releases of our software and put out new ones annually the version is a very important piece of information. There being 5 different ways to get at that data is not inherently bad since each way likely is most useful to different subsets of our users. To allow people to scratch their own itch, here specifically, seems like an easy win in making the project visibly responsive to the community.
David J.