On Oct 13, 2011, at 7:09 AM, Alex Hunsaker wrote:
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Oct 12, 2011 at 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
The core of the problem seems to be that if SvROK(sv) then
the code assumes that it must be intended
Alex Hunsaker bada...@gmail.com writes:
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Oct 12, 2011 at 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
The core of the problem seems to be that if SvROK(sv) then
the code assumes that it must be intended to convert that
On Oct 13, 2011, at 11:02 AM, Tom Lane wrote:
I'm working through this patch now. Does anyone object to having the
array-to-non-array-result-type and hash-to-non-rowtype-result-type cases
throw errors, rather than returning the rather useless ARRAY(...) and
HASH(...) strings as pre-9.1 did?
David E. Wheeler da...@kineticode.com writes:
On Oct 13, 2011, at 11:02 AM, Tom Lane wrote:
I'm working through this patch now. Does anyone object to having the
array-to-non-array-result-type and hash-to-non-rowtype-result-type cases
throw errors, rather than returning the rather useless
On Oct 13, 2011, at 11:25 AM, Tom Lane wrote:
Certainly not in 9.2, no. Not sure about 9.1, though.
Well, right now 9.1 is returning some rather random results. If we
don't change it, someone might claim that later releases ought to be
compatible with that ...
Okay then, works for me.
D
On Oct 13, 2011, at 9:02 PM, Tom Lane wrote:
Alex Hunsaker bada...@gmail.com writes:
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Oct 12, 2011 at 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
The core of the problem seems to be that if SvROK(sv) then
the code
Alex Hunsaker bada...@gmail.com writes:
This gets rid of of most of the if/else chain and the has_retval crap
in plperl_handl_func(). Instead we let plperl_sv_to_datum() do most of
the lifting. It also now handles VOIDOID and checks that the request
result oid can be converted from the perl
On Thu, Oct 13, 2011 at 16:05, Tom Lane t...@sss.pgh.pa.us wrote:
Applied with some further hacking of my own to clean up memory leaks
and grotty coding.
Thanks!
BTW after seeing it I agree passing in fcinfo (and the other fixes) to
plperl_sv_to_datum() is better.
--
Sent via pgsql-hackers
Hi,
An example in the PG documentation gives an error:
http://www.postgresql.org/docs/9.1/interactive/plperl-global.html
CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$
$_SHARED{myquote} = sub {
my $arg = shift;
$arg =~ s/(['\\])/\\$1/g;
return '$arg';
};
On Oct 12, 2011, at 2:16 AM, Amit Khandekar wrote:
CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$
$_SHARED{myquote} = sub {
my $arg = shift;
$arg =~ s/(['\\])/\\$1/g;
return '$arg';
};
$$ LANGUAGE plperl;
SELECT myfuncs(); /* initializes the function
David E. Wheeler da...@kineticode.com
CACoZds2D+0h-5euAxfpd9gQmiiW_MW9uv250Woz0=ego0sz...@mail.gmail.com writes:
On Oct 12, 2011, at 2:16 AM, Amit Khandekar wrote:
CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$
$_SHARED{myquote} = sub {
my $arg = shift;
$arg =~ s/(['\\])/\\$1/g;
On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
Well, the real question is why a function declared to return VOID cares
at all about what the last command in its body is. If this has changed
since previous versions then I think it's a bug and we should fix it,
not just change the example.
It
David E. Wheeler da...@kineticode.com writes:
On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
Well, the real question is why a function declared to return VOID cares
at all about what the last command in its body is. If this has changed
since previous versions then I think it's a bug and we
On Wed, Oct 12, 2011 at 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
Well, the real question is why a function declared to return VOID cares
at all about what the last command in its body is. If this has
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Oct 12, 2011 at 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
The core of the problem seems to be that if SvROK(sv) then
the code assumes that it must be intended to convert that to an array or
composite, no matter
15 matches
Mail list logo
