On Tue, Aug 28, 2012 at 11:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
> 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
> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Amit Kapila||Date: 2012-08-29 10:08:12|
|Subject: Re: wal_buffers|
|Previous:||From: Kohei KaiGai||Date: 2012-08-29 09:18:56|
|Subject: Re: [v9.3] writable foreign tables|