Thread: 8.1.4 compile problem
Hi all, i am compiling postgresql 8.1.4 on AMB x86_64 platform. configure runs fine but shows output (snippet shown) as follows: ... checking for int8... no checking for uint8... no checking for int64... no checking for uint64... no ... my gcc -v gives me: Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix--disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk--host=x86_64-redhat-linux Thread model: posix gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) how can i add int8,uint8,int64 and uint64 functionality into postgres ? are there any special flags that i am missing ? tia, regards, KM
Hi, On Friday 29 September 2006 11:01, km wrote: | i am compiling postgresql 8.1.4 on AMB x86_64 platform. | configure runs fine but shows output (snippet shown) as follows: | ... | checking for int8... no | checking for uint8... no | checking for int64... no | checking for uint64... no I'd say, this is expected output from configure. Configure is just a mechanism to help constructing an abstraction for different types of OS (i.e. things like "can we use this C type? Do we need to use another type instead?"). [...] | how can i add int8,uint8,int64 and uint64 functionality into postgres ? are | there any special flags that i am missing ? The "smallint", "integer" and "bigint" types are available regardless of that output from configure. Ciao, Thomas -- Thomas Pundt <thomas.pundt@rp-online.de> ---- http://rp-online.de/ ----
On Fri, Sep 29, 2006 at 11:48:09AM +0200, Thomas Pundt wrote: > I'd say, this is expected output from configure. Configure is just a mechanism > to help constructing an abstraction for different types of OS (i.e. things > like "can we use this C type? Do we need to use another type instead?"). > > [...] > | how can i add int8,uint8,int64 and uint64 functionality into postgres ? are > | there any special flags that i am missing ? > > The "smallint", "integer" and "bigint" types are available regardless of that > output from configure. I was in a doubt if int64,int8,uint64 and uint8 are not supported after setting up the db. thanks for clarifying my doubt. will proceed with gmake :) regards, KM --
> > I'd say, this is expected output from configure. Configure is just a mechanism > > to help constructing an abstraction for different types of OS (i.e. things > > like "can we use this C type? Do we need to use another type instead?"). > > | how can i add int8,uint8,int64 and uint64 functionality into postgres ? are > > | there any special flags that i am missing ? > > > > The "smallint", "integer" and "bigint" types are available regardless of that > > output from configure. > > I was in a doubt if int64,int8,uint64 and uint8 are not supported after setting up the db. > thanks for clarifying my doubt. will proceed with gmake :) > regards, > KM let me add this too: i have compiled postgres 8.1.4 even if configure didnt detect int8,uint8,int64 and uint64. i have tried to create a test table with datattype as int64 , but it says no such datatype, same is with uint8 an uint64datatypes. of the four mentioned above, int8 only is recognised as a datatype. which means i have compiled postgresqlwithout int64/uint64 support ??? any gotchas ? tia regards, KM
km <km@mrna.tn.nic.in> writes:
> i have compiled postgres 8.1.4 even if configure didnt detect
> int8,uint8,int64 and uint64. i have tried to create a test table with
> datattype as int64 , but it says no such datatype, same is with uint8
> an uint64 datatypes.
At the SQL level, these datatypes are named after byte sizes not bit
sizes, ie, int2, int4, int8. Or you might prefer smallint, int, bigint.
There are no unsigned types.
regards, tom lane
> At the SQL level, these datatypes are named after byte sizes not bit > sizes, ie, int2, int4, int8. Or you might prefer smallint, int, bigint. > There are no unsigned types. > > regards, tom lane > oh!! that makes it clear :) thanks! regards, KM