Re: SPI bug.
От | Thomas Hallgren |
---|---|
Тема | Re: SPI bug. |
Дата | |
Msg-id | thhal-0T8JSA3tMyiccraFqvAROWmP+B00Ws1@mailblocks.com обсуждение исходный текст |
Ответ на | Re: SPI bug. (Neil Conway <neilc@samurai.com>) |
Список | pgsql-hackers |
Neil Conway wrote: > 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. Using long means that you sometimes get a 32-bit value and sometimes a 64-bit value, I think we agree on that. There's no correlation between getting a 64-bit value and the fact that you run on a 64-bit platform since many 64-bit platforms treat a long as 32-bit. I think we agree on that too. If the objective behind using a long is that you get a data-type that followes the CPU register size then that objective is not met. No such data-type exists unless you use C99 intptr_t (an int that can hold a pointer). You could of course explicitly typedef a such in c.h but AFAICS, there is no such definition today. By using a long you will: a) maximize the differences of the SPI interfaces between platforms. b) only enable 64-bit resultset sizes on a limited range of 64-bit platforms. Wouldn't it be better if you: a) Minimized the differences between platforms. b) Made a decision to either use 32- or 64-bit resultset sizes (my preference would be the former) or to conseqently used 32-bit resultset sizes on 32-bit platforms and 64-bit resultset sizes on 64-bit platforms? Regards, Thomas Hallgren
В списке pgsql-hackers по дате отправления: