On Tue, Aug 28, 2012 at 11:23 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
