Joe Conway <mail@joeconway.com> writes:
> 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.
Yup, that was the idea ;-)
> 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
But there *is* a problem: tuples conforming to test's tupledescriptor
must actually still have three columns. If the function only outputs
two columns, it won't work.
You might possibly be able to make it work by restructuring the tuple to
have a null column in the middle, but I'm not sure about all the
consequences.
In the meantime, tupledesc_mismatch *is correct as it stands* --- if the
test it embodies is not satisfied, you will get core dumps. What you
would need to do if you do not like the present behavior is to be
willing to restructure the function's result tuple.
I believe that there are comparable problems in the other direction:
it's possible that the tuple actually returned by the function might
contain attisdropped columns that you'd need to ignore to make it match
up to the expected result type. I'm not quite sure about how to put
together mapping logic that handles all these cases, but it could
probably be done.
However, all this is just the tip of the iceberg. Suppose I have
defined a view
CREATE VIEW v AS SELECT a, b, c FROM myfunction()
where myfunction returns a rowtype containing a,b,c. What happens if
someone drops column b from the table defining the rowtype?
regards, tom lane
