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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
