Patch applied. Thanks.
---
David Fetter wrote:
On Sat, Jul 30, 2005 at 09:47:58AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
You have rolled 2 problems into one - spi_query+spi_fetchrow does not
David Fetter wrote:
*** 716,724
listitem
para
! In the current implementation, if you are fetching or returning
! very large data sets, you should be aware that these will all go
! into memory.
/para
/listitem
/itemizedlist
--- 766,776
On Sat, Jul 30, 2005 at 09:47:58AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
You have rolled 2 problems into one - spi_query+spi_fetchrow does not
address the issue of returning large data sets.
Suggest instead:
[suggestion]
Revised patch attached. Thanks for catching this
Would someone who knows perl update plperl.sgml and send me a patch?
Also, is this still true in 8.1:
In the current implementation, if you are fetching or returning
very large data sets, you should be aware that these will all go
into memory.
On Fri, Jul 29, 2005 at 11:24:37PM -0400, Bruce Momjian wrote:
Would someone who knows perl update plperl.sgml and send me a patch?
Also, is this still true in 8.1:
In the current implementation, if you are fetching or returning
very large data sets, you should be aware that
In the latest HEAD, a PL/Perl function that returns a list value
instead of a reference causes a segmentation fault:
CREATE FUNCTION foo() RETURNS integer[] AS $$
return (1, 2, 3, 4);
$$ LANGUAGE plperl;
SELECT foo();
server closed the connection unexpectedly
Here's the stack trace:
#0
Michael Fuhr wrote:
In the latest HEAD, a PL/Perl function that returns a list value
instead of a reference causes a segmentation fault:
CREATE FUNCTION foo() RETURNS integer[] AS $$
return (1, 2, 3, 4);
$$ LANGUAGE plperl;
SELECT foo();
server closed the connection unexpectedly
Here's the
On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote:
Note that all plperl functions are called in scalar context, and it is
always wrong to return a list (as opposed to a listref). In fact, the
value received might surprise you even if it worked (it would be the
value of the
Alvaro Herrera wrote:
On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote:
Note that all plperl functions are called in scalar context, and it is
always wrong to return a list (as opposed to a listref). In fact, the
value received might surprise you even if it worked (it
Andrew Dunstan [EMAIL PROTECTED] writes:
Michael Fuhr wrote:
In the latest HEAD, a PL/Perl function that returns a list value
instead of a reference causes a segmentation fault:
Patch below fixes the SEGV, and you will see instead:
Applied, thanks.
regards, tom lane
On Tue, Jul 12, 2005 at 03:45:55PM -0400, Andrew Dunstan wrote:
Alvaro Herrera wrote:
On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote:
Note that all plperl functions are called in scalar context, and
it is always wrong to return a list (as opposed to a listref). In
David Fetter wrote:
On Tue, Jul 12, 2005 at 03:45:55PM -0400, Andrew Dunstan wrote:
In perl, if there is any ambiguity it is the called function that is
responsible for checking, not the caller. See perldoc -f
wantarray. PLPerl explicitly passed G_SCALAR as a flag on all
calls to plperl
On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote:
Note that all plperl functions are called in scalar context, and it is
always wrong to return a list (as opposed to a listref). In fact, the
value received might surprise you even if it worked (it would be the
value of the
13 matches
Mail list logo