Re: SPI bug. - Mailing list pgsql-hackers

From Thomas Hallgren
Subject Re: SPI bug.
Date
Msg-id thhal-0T8JSA3tMyiccraFqvAROWmP+B00Ws1@mailblocks.com
Whole thread Raw
In response to Re: SPI bug.  (Neil Conway <neilc@samurai.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: BTW, if anyone wants to work on it...
Next
From: Tatsuo Ishii
Date:
Subject: bitmap scan and explain analyze