Re: SPI bug.

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