Re: SPI bug.

From: Neil Conway <neilc(at)samurai(dot)com>
To: Thomas Hallgren <thhal(at)mailblocks(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SPI bug.
Date: 2005-05-03 01:02:38
Message-ID: 4276CDAE.2060200@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Hallgren wrote:
> Tom Lane wrote:
>> Furthermore, we have never promised ABI-level compatibility across
>> versions inside the backend, and we are quite unlikely to make such
>> a promise in the foreseeable future.
>>
> I know that no promises has been made but PostgreSQL is improved every
> day and this would be a very easy promise to make.

Binary compatibility of backend APIs is by no means a "very easy promise
to make," nor would it be a good idea in any case.

> Also, the interpretation of the definition vary between compiler
> vendors. On Windows Itanium, the int is 32 bit. On Unix it's 64.

`int' is 32 bit on most modern platforms I can think of. Perhaps you're
thinking of `long', which is indeed 64-bit on many 64-bit Unixen but
32-bit on 64-bit Windows (BTW, this likely means that Postgres is
completely broken on 64-bit Windows: sizeof(Datum) == sizeof(unsigned
long) == 4, sizeof(void *) == 8).

> The 1998 revision of C declares the following types for a good reason:
>
> int8_t , int16_t, int32_t int64_t,
> uint8_t, uint16_t, uint32_t, uint64_t.

We don't currently depend on C99, and not all platforms have a 64-bit
datatype. In any case, I'm still unconvinced that using `int' and `long'
in backend APIs is a problem.

-Neil

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Jowett 2005-05-03 01:49:56 Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)
Previous Message Andrew Dunstan 2005-05-03 00:04:49 Re: [HACKERS] Decision Process WAS: Increased company involvement