Re: version() output vs. 32/64 bits

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: version() output vs. 32/64 bits
Date: 2009-01-07 06:46:09
Message-ID: Pine.GSO.4.64.0901070126570.8477@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 31 Dec 2008, Tom Lane wrote:

> No one has asked for access to individual components of the version
> string, other than the PG version number itself, which we already dealt
> with.

I think I'm now up to having wrote something to break apart the output
from version() into individual fields for 3 different companies. If
you're got a bunch of database servers on a network, it seems inevitable
that eventually you'll end up collecting information about them via
queries against port 5432 for managing everything, and the output from
version() always ends up on that hotlist. I'd bet the only reason this
hasn't been a specific TODO request before is because it is relatively
easy (albeit fragile) to parse it out manually.

There are also some use cases related to writing tuning tools, where for
example the platform bit size determines what range some settings can
reach. Again, you can just parse it out if that starts being included,
but it would be cleaner to grab just that one piece. (Right now I just
look at the maximum value for one of the settings I know changes size to
figure that out when this pops up)

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-01-07 07:34:05 Re: Visibility map and freezing
Previous Message KaiGai Kohei 2009-01-07 06:46:03 Re: New patch for Column-level privileges