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 system it works since int size=long size.

I am using 8.0.2 (i.e. the repositioning bug is already fixed here).

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.
(FETCH_ALL at parsenodes.h)

Regards,
tzahi.

WARNING TO SPAMMERS: see at
http://members.lycos.co.uk/my2nis/spamwarning.html



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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
probably not be wise to backport, though, as it is probably not worth
breaking ABI compatibility for SPI during a stable release series.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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_execute_plan(), SPI_cursor_fetch(), and SPI_cursor_move().

I also updated PL/Python, which was invoking SPI_execute() with an `int'
parameter. PL/Tcl could be updated as well, but it seems the base Tcl
package doesn't provide a Tcl_GetLong() function. PL/Perl could also be
updated (plperl_spi_exec()), but I don't know XS, so I will leave that
to someone else.

Barring any objections, I'll apply this to HEAD tomorrow.

-Neil


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On 2005-05-01, Neil Conway <neilc@samurai.com> 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
> "long" for the "count" parameter is the right fix for HEAD. It would
> probably not be wise to backport, though, as it is probably not worth
> breaking ABI compatibility for SPI during a stable release series.

While you're at it, how about a way to specify WITH SCROLL for a cursor
created in SPI? At the moment, SPI_cursor_open hardwires the scroll option
according to the result of ExecSupportsBackwardScan.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

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(), SPI_execp(),
> SPI_execute_plan(), SPI_cursor_fetch(), and SPI_cursor_move().
>
> I also updated PL/Python, which was invoking SPI_execute() with an `int'
> parameter. PL/Tcl could be updated as well, but it seems the base Tcl
> package doesn't provide a Tcl_GetLong() function. PL/Perl could also be
> updated (plperl_spi_exec()), but I don't know XS, so I will leave that
> to someone else.
>
> Barring any objections, I'll apply this to HEAD tomorrow.
>
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, wouldn't it be better to use
something that is fixed in size here too? I.e. int32 or perhaps int64?

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

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.

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 -- 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?)

-Neil

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Neil Conway <neilc@samurai.com> 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" should
have at least acceptable performance on all machines, "long long" is
another story) and there is no demonstrated need.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

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 majordomo@postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 implication is yet another change to the SPI interfaces.
Why not decide, once and for all and right now, what the size of this
integer should be and then *start* with a change of the interface. The
change of the underlying implementation can come later. Now you
effectively force a second change that will make things incompatible
should you decide to change the executor in the future.

Regards,
Thomas Hallgren



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly