Greg Smith wrote:
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
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
So what do we want to do for 8.4? Add 32/64-bit version() indicator and
add OUT parameters to the TODO list?
+1. There seems a good case for making the 32/64bit distinction
visible somewhere, and the text version
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
Zdenek Kotala wrote:
Alvaro Herrera p??e v st 31. 12. 2008 v 12:54 -0300:
Maybe we could have a separate function which returned the info in
various columns (OUT params). Maybe it would be useful to normalize the
info as reported the buildfarm, which right now is a bit ad-hoc.
+1 it
Bruce Momjian br...@momjian.us writes:
So what do we want to do for 8.4? Add 32/64-bit version() indicator and
add OUT parameters to the TODO list?
+1. There seems a good case for making the 32/64bit distinction
visible somewhere, and the text version string is as good as anyplace.
I think
Alvaro Herrera píše v st 31. 12. 2008 v 12:54 -0300:
Maybe we could have a separate function which returned the info in
various columns (OUT params). Maybe it would be useful to normalize the
info as reported the buildfarm, which right now is a bit ad-hoc.
+1 it sounds good.
Zdenek
Bruce Momjian píše v st 31. 12. 2008 v 11:22 -0500:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
Maybe we should separate all that, e.g.,
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
So what do we want to do for 8.4? Add 32/64-bit version() indicator and
add OUT parameters to the TODO list?
+1. There seems a good case for making the 32/64bit distinction
visible somewhere, and the text version string is as good
Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
... Moreover, there does not actually seem to be a
way to find out whether you have a 32-bit or a 64-bit build (except by
using OS tools).
I think the basic definition of 32 bit or 64 bit, certainly for
our
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
... Moreover, there does not actually seem to be a
way to find out whether you have a 32-bit or a 64-bit build (except by
using OS tools).
I think the basic
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
Maybe we should separate all that, e.g.,
SELECT version(); = 'PostgreSQL 8.4devel'
SELECT pg_host_os(); =
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
Maybe we should separate all that, e.g.,
SELECT version(); = 'PostgreSQL 8.4devel'
SELECT
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
Maybe we should separate all that, e.g.,
SELECT version(); = 'PostgreSQL 8.4devel'
SELECT
Bruce Momjian wrote:
Tom Lane wrote:
I didn't actually see a user request for finding out the pointer width,
either, but if there is one then Bruce's proposal seems fine.
It is true no one asked for this information except Peter (I assume for
just academic reasons),
Huh, count us
On Wednesday 31 December 2008 18:22:50 Bruce Momjian wrote:
It is true no one asked for this information except Peter (I assume for
just academic reasons),
no
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hello
2008/12/31 Alvaro Herrera alvhe...@commandprompt.com:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
Maybe we should separate all that,
Pavel Stehule pavel.steh...@gmail.com writes:
2008/12/31 Alvaro Herrera alvhe...@commandprompt.com:
Maybe we could have a separate function which returned the info in
various columns (OUT params). Maybe it would be useful to normalize the
info as reported the buildfarm, which right now is a
On Wed, Dec 31, 2008 at 01:25:34PM -0500, Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2008/12/31 Alvaro Herrera alvhe...@commandprompt.com:
Maybe we could have a separate function which returned the info
in various columns (OUT params). Maybe it would be useful to
It has been pointed out to me that the output of the version() function
is becoming more confusing in face of mixed 32/64 bit environments.
Output like i486-pc-linux-gnu just says what kind of kernel the build
environment has, not whether you actually have a IA-32 build.
Conversely,
Peter Eisentraut pete...@gmx.net writes:
... Moreover, there does not actually seem to be a
way to find out whether you have a 32-bit or a 64-bit build (except by
using OS tools).
I think the basic definition of 32 bit or 64 bit, certainly for
our purposes, is sizeof(void *). That is
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
... Moreover, there does not actually seem to be a
way to find out whether you have a 32-bit or a 64-bit build (except by
using OS tools).
I think the basic definition of 32 bit or 64 bit, certainly for
our purposes, is
21 matches
Mail list logo
