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 everything just by looking at the code in pl/pgsql.

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Thomas Hallgren <thhal@mailblocks.com> 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's hard and somewhat time consuming to try to
> deduct everything just by looking at the code in pl/pgsql.

Could you give more details about what problem you are having? Simply
recompiling an existing PL shouldn't fail (of course, it wouldn't know
about OUT parameters either).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> Thomas Hallgren <thhal@mailblocks.com> 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's hard and somewhat time consuming to try to
>>deduct everything just by looking at the code in pl/pgsql.
>
>
> Could you give more details about what problem you are having? Simply
> recompiling an existing PL shouldn't fail (of course, it wouldn't know
> about OUT parameters either).
>
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.

Some diffs on plperl helped me a bit. I found the new
get_call_result_type() function. I've made some assumptions that I would
like to verify the correctness of:

- I assume that by using the get_call_result_type() PL/Java will not
need any specific handling of functions returning OUT parameters since
they are similar to functions returning a complex type.

- The TupleDesc returned by the get_call_result_type() is not always
reachable using an Oid. I.e. I cannot use TypeGetTupleDesc(oid, NIL)
with the Form_pg_proc.prorettype of my function as the first argument.

- The Form_pg_proc.pronargs denotes the number of IN parameters, i.e.
its safe to access proargtypes.values[idx] with an idx ranging from 0 to
pronargs - 1.

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Thomas Hallgren <thhal@mailblocks.com> 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 the get_call_result_type() PL/Java will not
> need any specific handling of functions returning OUT parameters since
> they are similar to functions returning a complex type.

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() is not always
> reachable using an Oid. I.e. I cannot use TypeGetTupleDesc(oid, NIL)
> with the Form_pg_proc.prorettype of my function as the first argument.

That was true before for the RECORD case.

> - The Form_pg_proc.pronargs denotes the number of IN parameters, i.e.
> its safe to access proargtypes.values[idx] with an idx ranging from 0 to
> pronargs - 1.

Right, pronargs/proargtypes still denote the call signature and thus
only count IN (and INOUT) parameters.

One thing to be a bit wary of is that when OUT arguments are present,
subscripts in proargnames line up with proallargtypes not proargtypes.
I dunno if you are using proargnames at all, but if you are, the code
is likely to misbehave if it doesn't know that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

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() is not always
>>reachable using an Oid. I.e. I cannot use TypeGetTupleDesc(oid, NIL)
>>with the Form_pg_proc.prorettype of my function as the first argument.
>
>
> That was true before for the RECORD case.
>
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?

>
>>- The Form_pg_proc.pronargs denotes the number of IN parameters, i.e.
>>its safe to access proargtypes.values[idx] with an idx ranging from 0 to
>>pronargs - 1.
>
>
> Right, pronargs/proargtypes still denote the call signature and thus
> only count IN (and INOUT) parameters.
>
> One thing to be a bit wary of is that when OUT arguments are present,
> subscripts in proargnames line up with proallargtypes not proargtypes.
> I dunno if you are using proargnames at all, but if you are, the code
> is likely to misbehave if it doesn't know that.
>
Thanks a lot. Now I know how to go about this. Seems pretty stright
forward. Nice work!

Regards,
Thomas Hallgren

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Thomas Hallgren <thhal@mailblocks.com> 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 to look in fcinfo->resultinfo to see
if an expectedDesc is supplied via a ReturnSetInfo. get_call_result_type()
handles that case along with the OUT-parameters case and the returns-a-
named-composite-type case, so it makes things a little easier and more
consistent.

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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
returning SETOF RECORD in all versions. 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?

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Thomas Hallgren <thhal@mailblocks.com> 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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Tom Lane wrote:

>Thomas Hallgren <thhal@mailblocks.com> 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 javatest.recordExample(int, int) returns record
as 'org.postgresql.pljava.example.ComplexReturn.compl exReturn' immutable
language java;
CREATE FUNCTION
thhal=# select * from javatest.recordExample(3, 4) as (foo int, bar int,
baz timestamptz);
ERROR: could not determine row description for function returning record

(the error occurs since I make an attempt to fetch by Oid when the
TupleDesc is NULL. Oid in this case is RECORDOID).

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Thomas Hallgren <thhal@mailblocks.com> writes:
> thhal=# create function javatest.recordExample(int, int) returns record
> as 'org.postgresql.pljava.example.ComplexReturn.compl exReturn' immutable
> language java;
> CREATE FUNCTION
> thhal=# select * from javatest.recordExample(3, 4) as (foo int, bar int,
> baz timestamptz);
> ERROR: could not determine row description for function returning record

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 :-(

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings