On Wed, Sep 02, 2009 at 12:36:00PM -0400, Robert Haas wrote:
> On Wed, Sep 2, 2009 at 11:55 AM, Sam Mason<sam@samason.me.uk> wrote:
> > In fact it doesn't seem to want to play ball at all. Even given the
> > apparently unambiguous:
> >
> > SELECT 1+add(1,2);
> > or
> > SELECT 'hi'||add(1,2);
> >
> > It doesn't get anywhere. No need for "text 'hi'" in the second one
> > because || isn't defined for values of integer type.
>
> Right. This is exactly the sort of thing that languages with real
> type inference have no problem handling. Of course, ML for example
> doesn't allow overloading precisely because (AIUI) it makes type
> inference difficult. It would be awesome if we could make this work
> though.
Difficult, but not intractable. Haskell has done this sort of thing for
quite a while; although it handles ad-hoc polymorphism differently than
PG does. You basically end up saying how much polymorphism you want
to allow for each function, for example the return type of an operator
(in PG) is determined exactly by the type of its arguments. In Haskell
you would have the power to say, if you so wanted, that the type of an
operator's RHS is determined exactly by the type of its LHS and return
type, or even, in the most general case, that it's parametrized over all
three types. Obviously the more types you leave free the more typing
you have to do specifying all the types as the type-inference has less
leverage to work with.
I've been trying to think about how to apply a more modern type system
to PG for a while and hence my comments about how things like NULL
rows should be handled are based on this and may come across as rather
dogmatic sometimes, it's about the only way I can get things to hold
together without introducing much more complexity than seems strictly
necessary.
--
Sam http://samason.me.uk/
