- we can't use estate->rsi for the RETURN case, at least as presently
implemented, because that is not always filled-out -- the example I gave
before shows how because we don't check for a compatible TupleDesc when
estate->rsi is NULL, we end up returning a value that is incompatible
with the function's declared return type

I expected so when rsi is NULL, then I haven't any info about desired record type, and then I have to skip checking for a compatibility (and I can it to do, because this is clean error, then is not necessery conversion, and next step do exception and error if returned type is wrong).

I found different problem. It has maybe relation with Tom Lane's changes about returning one field records. And maybe wee need test for conversion everytime

create or replace function a() returns record as $$ return (1); $$ language plpgsql;

is syntax clean, it's row expression, but select a() ends with wrong result type supplied in RETURN. With change return (1,2), all works fine. return row(1) works well too.

- therefore, we need to use some other way to get the TupleDesc of the
function's declared return type. Offhand I think we can use
estate->fn_rettype (plus the funcapi stuff for handling RECORDOID), but
I haven't had a chance to try it yet.

testing estate->fn_rettype is safer, but what is efectivity? Is necessery caching TupleDesc in retturn statement? I don't know? I don't study mechanism when is rsi valid or not. But I found some samples in source, when rsi was used for same purpose.


Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to