On Tue, Aug 28, 2012 at 11:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> That argument would hold water if we got rid of every single usage of
> overloading in the system-defined operators/functions, which as you well
> know is not an attractive idea. Since that's not going to happen,
> arguing for this on the basis that your customers don't overload
> function names is missing the point. Any loosening of the rules is
> going to create issues for system-function resolution ... unless you're
> going to propose that we somehow do this differently for user and system
> defined functions.
Obviously not.
> An example of the sort of problem that I don't want to hear about
> ever again is somebody trying to use max() on a "point" column.
> We don't have linear sort ordering for points, so this is nonsensical
> and should draw an error. Which it does, today.
Much as I hate to say it, I have to admit I find this to be a
compelling argument.
> Really? You've not had experience with very many programming languages,
> then. Just about every one I've ever dealt with that's at a higher
> conceptual level than C or BASIC *is* sticky about this sort of thing.
In terms of type-strictness, it runs the gamut. You have things like
Perl where datatypes barely exist at all and silent (sometimes
confusing) conversions are performed nary a second thought, and at the
other end of the spectrum you have things like ML which are incredibly
fanatic about type-checking. But both Perl and ML and, as far as I
know, most of what's in between make a virtue of terseness. The
exceptions are things like Ada and Cobol, which are not IMHO the sorts
of thing we ought to be trying to emulate.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company