Re: SPI bug.

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: SPI bug.
Дата
Msg-id 4276CDAE.2060200@samurai.com
обсуждение исходный текст
Ответ на SPI bug.  (Tzahi Fadida <tzahi_ml@myrealbox.com>)
Ответы Re: SPI bug.  (Thomas Hallgren <thhal@mailblocks.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Andrew Dunstan"
Дата:
Сообщение: Re: [pgsql-advocacy] Decision Process WAS: Increased company involvement
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_locks needs a facelift