From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
To: | Neil Conway <neilc(at)samurai(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 07:35:41 |
Message-ID: | thhal-0T8JSA3tMyiccraFqvAROWmP+B00Ws1@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2005-05-03 09:11:28 | bitmap scan and explain analyze |
Previous Message | Tom Lane | 2005-05-03 06:45:09 | BTW, if anyone wants to work on it... |