Neil Conway <neilc@samurai.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> There is a rather nasty bug left (Sir Mordred would likely call it a
>> DOS possibility ;-)) --- RETURN NEXT doesn't seem to be checking that
>> the row or record variable it is given actually matches the declared
>> return type of the plpgsql function.
> Yes, I probably should have mentioned that. I considered adding the
> code to generate a TupleDesc for each call of RETURN NEXT and compare
> that to the TupleDesc used for the previous RETURN NEXT statement, but
> that seems to be quite expensive: equalTupleDescs() is not cheap, and
> neither is TyoeGetTupleDesc() (which is required for returning
> non-RECORD vars). Since RETURN NEXT will often be called many times
> within a single function, the performance hit seems unappealing. Is
> there a better way?
Well, you don't need or want a full equalTupleDescs() comparison.
All you care about is that the number and types of the columns match
--- see tupledesc_mismatch() in nodeFunctionscan.c. That doesn't
seem terribly expensive. The hard part seems to be getting the tupdesc
to compare to. For record variables it seems to be available for free,
but I'm less sure about the other two cases. Probably row variables
could be modified to store a tupdesc. Not sure what's the best thing
to do with scalar results.
As for TypeGetTupleDesc, that's a red herring: you shouldn't need to do
that more than once, because it's used to compute a tupdesc for the
declared function return type, which isn't gonna change. I'm not sure
you need do it at all in the row or record cases --- you should be
looking to the actual type of the given data, not the declared function
type (think about RECORD-returning functions).
regards, tom lane