Skip site navigation (1) Skip section navigation (2)

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

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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: 2008-12-31 18:13:03
Message-ID: 162867790812311013k27276e8ek8ddbe4968264965a@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hello

2008/12/31 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Tom Lane wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)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();        => 'bsdi4.3.1'
>> > SELECT pg_host_cpu();       => 'i386' (although this is still faulty, as per my
>> > original argument; needs some thought)
>> > SELECT pg_compiler();       => 'GCC 2.95.3'
>> > SELECT pg_pointer_size(); => 4 (or 32) (this could also be a SHOW variable)
>>
>> Seems like serious overkill.  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.
>
> 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 variables - It is cheep.

regards
Pavel Stehule

> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-12-31 18:21:34
Subject: lazy_truncate_heap()
Previous:From: Tom LaneDate: 2008-12-31 18:08:20
Subject: Re: [patch] Reformat permissions in \l+ (like \z does)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group