Neil Conway wrote:
We don't currently depend on C99, and not all platforms have a 64-bit
datatype. In any case, I'm still unconvinced that using `int' and
`long' in backend APIs is a problem.
Using long means that you sometimes get a 32-bit value and sometimes a
64-bit value, I think we agree on
Thomas Hallgren wrote:
Tom Lane wrote:
Furthermore, we have never promised ABI-level compatibility across
versions inside the backend, and we are quite unlikely to make such
a promise in the foreseeable future.
I know that no promises has been made but PostgreSQL is improved every
day and this wou
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Exactly. Why should a user of the SPI API be exposed to or even
concerned with this at all? As an application programmer you couldn't
care less. You want your app to perform equally well on all platforms
without surprises. IMHO, Post
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Exactly. Why should a user of the SPI API be exposed to or even
> concerned with this at all? As an application programmer you couldn't
> care less. You want your app to perform equally well on all platforms
> without surprises. IMHO, PostgreSQL shou
Neil Conway wrote:
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
Neil Conway wrote:
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.
One thing that I forgot. If you indeed will do something like that in
the future, the implic
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 la
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 lon
Neil Conway <[EMAIL PROTECTED]> writes:
> The reason the API types should use "long" is that the underlying
> executor APIs (e.g. ExecutorRun()) use "long". It might be a good idea
> to change the executor stuff to use int64s
No, it would not. There is a potential performance cost ("long" shoul
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++ type
Neil Conway wrote:
Neil Conway wrote:
I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
"long" for the "count" parameter is the right fix for HEAD.
Attached is a patch that implements this. A bunch of functions had to be
updated: SPI_execute(), SPI_execute_snapshot(), SPI_exec(
On 2005-05-01, Neil Conway <[EMAIL PROTECTED]> wrote:
> Tzahi Fadida wrote:
>> I think the solution can be either changing the FETCH_ALL to
>> INT_MAX or changing the interface parameter count and subsequent usages
>> to long.
>
> I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
Neil Conway wrote:
I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
"long" for the "count" parameter is the right fix for HEAD.
Attached is a patch that implements this. A bunch of functions had to be
updated: SPI_execute(), SPI_execute_snapshot(), SPI_exec(), SPI_execp(),
SPI
Tzahi Fadida wrote:
I think the solution can be either changing the FETCH_ALL to
INT_MAX or changing the interface parameter count and subsequent usages
to long.
I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
"long" for the "count" parameter is the right fix for HEAD. It would
Hi,
While trying to determine if SPI_cursor_move can rewind
(and receiving a great help from the guys at the irc), we
found out that since the count parameter is int
and FETCH_ALL is LONG_MAX then setting
the count parameter to FETCH_ALL to rewind
will not work on 64bit systems.
On my pIII 32 bit
15 matches
Mail list logo
