Re: OUT parameters in PL/Java - Mailing list pgsql-hackers

From Tom Lane
Subject Re: OUT parameters in PL/Java
Date
Msg-id 23752.1113516668@sss.pgh.pa.us
Whole thread Raw
In response to OUT parameters in PL/Java  (Thomas Hallgren <thhal@mailblocks.com>)
Responses Re: OUT parameters in PL/Java  (Thomas Hallgren <thhal@mailblocks.com>)
List pgsql-hackers
Thomas Hallgren <thhal@mailblocks.com> writes:
> Tom Lane wrote:
>> Hmm.  I think this is not your bug.  Is the call coming from
>> evaluate_function in clauses.c?  We need to either prevent that from
>> pre-evaluating a function returning RECORD, or fix it so it can pass
>> the expected tuple descriptor ... probably the former :-(

I committed a patch to prevent that problem.

> I've found another problem that might be related. The same example as 
> above but this time I use "returns setof record". Using the CVS head I 
> now get:

> thhal=# select * from javatest.recordExample(3, 4) as (foo int, bar int, 
> baz timestamptz);
> ERROR:  record type has not been registered

> this happens before the java_call_handler is called. Here's the stacktrace:

> #0  lookup_rowtype_tupdesc_noerror (type_id=2249, typmod=-1, noError=0 '\0')
>     at typcache.c:425
> #1  0x081f435b in lookup_rowtype_tupdesc (type_id=2249, typmod=-1)
>     at typcache.c:390
> #2  0x0812081a in ExecMakeTableFunctionResult (funcexpr=0x9c4e288,
>     econtext=0x9c4ded0, expectedDesc=0x9c4e068, returnDesc=0x9c52200)
>     at execQual.c:1298

Looking at the code, it appears that the java call handler *has* been
called once, and what it returned was a tuple that didn't carry any
type identification.  This is probably because you didn't call
BlessTupleDesc.  nodeFunctionscan.c formerly did that, and I suppose
it should keep doing it for backwards compatibility.  I put back the
call...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] NetBSD mac68k crashing on union regression test
Next
From: Tzahi Fadida
Date:
Subject: Multicolumn hash tables space complexity.