Tom Lane wrote:
Looking at the code, it appears that the java call handler *has* been
called once,
indeed. Obviously I didn't pay too much attention to the trace.
and what it returned was a tuple that didn't carry any
type identification. This is probably because you didn't call
BlessTupleDesc. n
Thomas Hallgren <[EMAIL PROTECTED]> 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 descrip
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
thhal=# create function javatest.recordExample(int, int) returns record
as 'org.postgresql.pljava.example.ComplexReturn.complexReturn' immutable
language java;
CREATE FUNCTION
thhal=# select * from javatest.recordExample(3, 4) as (foo
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> thhal=# create function javatest.recordExample(int, int) returns record
> as 'org.postgresql.pljava.example.ComplexReturn.complexReturn' immutable
> language java;
> CREATE FUNCTION
> thhal=# select * from javatest.recordExample(3, 4) as (foo int, bar
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
... The only thing that doesn't work
right now is a function that returns RECORD (not SETOF) since the rsinfo
in this case is NULL. Can you shed some light on that?
What's the test case exactly?
thhal=# create function javates
Tom Lane wrote:
You could do worse than to back-port get_call_result_type() into your
older branches and just leave out the code for the OUT parameter case.
Great advice! I went ahead and did just that. Now PL/Java handles
IN/INOUT/OUT parameters correctly with 8.1 and it handles functions
ret
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> ... The only thing that doesn't work
> right now is a function that returns RECORD (not SETOF) since the rsinfo
> in this case is NULL. Can you shed some light on that?
What's the test case exactly?
regards, tom lane
---
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> PL/Java will not handle the RECORD case gracefully at present I'm
> afraid. The 8.0 compatible version will need some improvements. How is
> the TupleDesc obtained in case of RECORD in 8.0.x? Is it the same in 7.4?
In 8.0 and before I think you have
Tom Lane wrote:
If you use that, it will look just the same as the existing situation
where you are declared to return RECORD and someone calls you with
a column name/type list in FROM. Whether you want any additional
smarts is up to you.
- The TupleDesc returned by the get_call_result_type() i
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> My compile failure was due to the change of proargtypes from Oid* to an
> oidvector. I initially thought that had something to do with OUT parameters.
No, not directly. The diffs needed for that are pretty simple though.
> - I assume that by using t
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
I've read about changes in CVS head needed to accomodate OUT parameters.
I tried to compile PL/Java and it fails (of course). Is there any brief
text somewhere that highligts the changes that where made and explains
how the new stuff wo
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I've read about changes in CVS head needed to accomodate OUT parameters.
> I tried to compile PL/Java and it fails (of course). Is there any brief
> text somewhere that highligts the changes that where made and explains
> how the new stuff works? It'
I've read about changes in CVS head needed to accomodate OUT parameters.
I tried to compile PL/Java and it fails (of course). Is there any brief
text somewhere that highligts the changes that where made and explains
how the new stuff works? It's hard and somewhat time consuming to try to
deduct
13 matches
Mail list logo
