Neil Conway wrote:
Thomas Hallgren wrote:
Since both int and long are types whos size that vary depending on platform, and since the SPI protocol often interfaces with other languages where the sizes are fixed
ISTM there are no "languages where the sizes are fixed". In this context, int and long are C and C++ types; types that happen to have the same name but different behavior (e.g. int and long in Java) are not the same type at all.
I fully agree that an int and long in Java is very different from an int or long in C/C++. Hence my proposal :-)
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.
The reason the API types should use "long" is that the underlying executor APIs (e.g. ExecutorRun()) use "long".
An API should ideally hide the internals of the underlying code so I'm not sure this is a valid reason. I would instead say that "An API should remain consistent over the range of platforms where it is supported". Especially if the intention with this API is to make the life easier for PL/<some language> authors.
It might be a good idea to change the executor stuff to use int64s -- then I'd have no issue with making a corresponding change to the SPI APIs. I guess the main objection to doing this is that a 64-bit integral type is not available on all platforms (at least in theory; are there any platforms we care about that don't have one?)
I'm sure there is some obscure platform where this matters. I don't know of one though and in my world there isn't. The Java Native Interface (JNI) uses the jlong type and it's required to be 64 bit. If PostgreSQL could be made to rely the int64, then we could get rid of the integer-datetimes conditional also. That would be nice.
For this purpose I wonder if there's a need to use int64's though. An int32 covers extremely huge result-sets. But perhaps I'm not visionary enough. I still remember the days when 640Kb RAM should be enough for all foreseeable future :-)
Regards, Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
