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
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
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian 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 strin
Tom Lane wrote:
> Bruce Momjian 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 anyplac
Bruce Momjian 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 the business abo
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.
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.
Zden
Bruce Momjian píše v st 31. 12. 2008 v 11:22 -0500:
> Tom Lane wrote:
> > Peter Eisentraut 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.,
On Wed, Dec 31, 2008 at 01:25:34PM -0500, Tom Lane wrote:
> "Pavel Stehule" writes:
> > 2008/12/31 Alvaro Herrera :
> >> 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 buildf
"Pavel Stehule" writes:
> 2008/12/31 Alvaro Herrera :
>> 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.
> All should be GUC read only
Hello
2008/12/31 Alvaro Herrera :
> Tom Lane wrote:
>> Peter Eisentraut 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()
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:
http://www.postgresql.org
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
Tom Lane wrote:
> Peter Eisentraut 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
Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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(); => 'bsdi4.3.1'
>
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut 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 definit
Bruce Momjian wrote:
> Tom Lane wrote:
>> Peter Eisentraut 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
Tom Lane wrote:
> Peter Eisentraut 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(vo
Peter Eisentraut 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 something that
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, amd64-pc-li
21 matches
Mail list logo
