Re: SPI bug.

Thomas Hallgren wrote:
> What I meant was that SPI will interface with languages where there is 
> no correspondence to a type who's size varies depending on platform and 
> that it therefore would be better to chose a type who's size will not vary.

My point is that since they are different types, the language itself 
will need to provide some mechanism for doing this type conversion 
_anyway_. 'int' and 'long' are used throughout the backend APIs, so I 
don't see the gain in only converting the SPI functions over to using 
int32/int64.

> An API should ideally hide the internals of the underlying code so I'm 
> not sure this is a valid reason.

Well, the executor allows you to specify a 64-bit count on platforms 
where "long" is 64-bit, and a 32-bit count otherwise. ISTM the most 
straightforward way to expose this to clients is to just make the 
parameter a "long". As I said before, we may or may not want to change 
the executor itself to use a constant-sized type, but as a matter of 
interface definition, I think using "long" makes the most sense.

BTW, patch applied to HEAD.

-Neil