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
