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

Reply via email to