Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> Hmmm, looks like nodeFunctionscan.c:tupledesc_mismatch needs to be
>> taught about attisdropped. I'll submit a patch this evening if no
>> one else gets to it first.
>
> Actually, I believe I deliberately left it like that because I was
> concerned about what would happen in this scenario. I don't think
> that changing tupledesc_mismatch to ignore attisdropped columns will
> make things work nicely. If a function is expecting to return
> (a,b,c) and then you drop b from the table that defines its return
> type, is the function likely to magically return (a,c)? I doubt it.
Assuming tupledesc_mismatch ignored attisdropped attributes, and the
function still output the dropped attribute, the error would be
triggered due to a mismatch. But then you could adjust your function and
be on your merry way.
In the case where the function is returning a whole table tuple (e.g.
select * from...), everthing should work correctly (and as expected).
Without this change, any table that has had a column dropped would not
be able to be used as a function's return type at all.
> Letting the code get past the mismatch check is likely to result in
> core dumps.
I don't see how. The code would still ensure that the returned tuple and
defined tuple match, wouldn't it?
start with table test, attributes (a,b,c)
drop attribute b from test
tupledesc_mismatch checks that function's output is (a,c)
if function actually outputs (a,c), no problem
Am I just being thick-headed?
Joe