Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You're not providing enough info to resolve_type to let it handle all
>> four cases correctly.

> No, resolve_type() is not at all specific to polymorphic aggregates. It 
> implements the rules of polymorphism that we previously agreed to, 
> namely that an ANYARRAY can be resolved by knowing any of these data 
> types at the time of function call:

> 1) the actual call type at the same position (i.e. argument number or
>     return type) as the ANYARRAY you're trying to resolve

> 2) the actual call type at a different position from the ANYARRAY you're
>     trying to resolve, as long as the declared type at that position is
>     either ANYARRAY or ANYELEMENT.

But you still need three pieces of info, and it's only being given two.
In the second case (where you know actual argument type at a different
position) you must know whether the other position's declared type is
anyarray or anyelement, and you can't assume it's the same as the one at
the position you want to resolve.

> Did you find a specific case where this falls down?

It fails to raise errors in cases where errors should be raised,
but instead delivers the wrong datatype as result.  It can also
incorrectly replace an arraytype by its element type ("ANYELEMENT"
doesn't require the actual type to not be an array --- unless
"ANYARRAY" is also used in the same declaration, and even then
it's only going to fail because we don't support arrays of arrays).

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to