Joe Conway <mail@joeconway.com> writes:
> I wrestled with the same issue last year.
>
> Offhand I don't know how hard it would be to do, but I wonder if when we see:
>
> argL IN (argR)
>
> we might be able to determine if argL and argR are of the same type or if argR
> is an array of argL, and act accordingly.
That would be nice and simple and clean, except that postgres's type system
doesn't work that way. It works backwards from every other language. Instead
of every variable and function return value having a rigid type and forcing
the interpretation of the surrounding expression, postgres seems to work top
down.
So in this case if argL or argR are functions or other expressions with
unknown types it tries to figure out how to interpret them to produce the type
it's looking for. In other words, what type those expressions are depends on
what the expression expects. What would you do with "foo() IN (array[1,2])" if
there are two functions called foo, one which returns an integer and one which
returns an integer[] ?
One of these days I'm going to suggest doing away with the whole "unknown"
concept and make function return types not part of the polymorphic signature.
That would make a lot of the type system weirdness go away. But it would mean
breaking with a lot of tradition. And of course it would be completely and
utterly not backwards compatible and I'll probably be laughed at.
--
greg
