Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> 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


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to