On Thu, Oct 13, 2011 at 16:05, Tom Lane 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 mailing list (pg
Alex Hunsaker 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 structure. For e
On Oct 13, 2011, at 9:02 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker wrote:
>>> On Wed, Oct 12, 2011 at 15:00, Tom Lane wrote:
The core of the problem seems to be that if SvROK(sv) then
the code assumes that it must be intended to conv
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
"David E. Wheeler" 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 ARRAY(...) and
>
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 di
Alex Hunsaker writes:
> On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker wrote:
>> On Wed, Oct 12, 2011 at 15:00, Tom Lane 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 wheth
On Oct 13, 2011, at 7:09 AM, Alex Hunsaker wrote:
> On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker wrote:
>> On Wed, Oct 12, 2011 at 15:00, Tom Lane 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
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker wrote:
> On Wed, Oct 12, 2011 at 15:00, Tom Lane 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 whether the declared result type
On Wed, Oct 12, 2011 at 15:00, Tom Lane wrote:
> "David E. Wheeler" 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 ve
"David E. Wheeler" 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 should fix it,
>
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.
I
"David E. Wheeler"
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;
>> return "'$arg'";
>> };
>> $$ LANGUAGE plperl;
>>
>> SELECT myfuncs(); /* in
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
14 matches
Mail list logo