On Thu, Feb 21, 2013 at 10:51 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> Sure: but that's another straw man: abuse of + operator is case of
> combining arbitrarily different behaviors (concatenation and
> arithmetic aggregation) into uniform syntax. This is bad, but a
> different thing. The right way to do it is to globally define the
> behavior and map it to types if and only if it makes sense. Again,
> you want clean separation of 'what you're doing' vs 'what you're doing
> it over'.
I'll buy that. So what's the globally defined behavior of a ~>
operator or a function called get() or even vals()? The problem is
that I don't know how we can be sure any definition we choose now
based on one example will be forward-compatible with things we want to
do later, perhaps involving completely unrelated data types with very
different semantics. It's not like there are an infinite number of
short, high-quality operator/function names.
> I'm not buying into the hype at all. I've been arguing (without much
> success) for years that throwing arcane type specific functions into
> the public namespace is incoherent, not the other way around.
> array_upper()? How about length() or count()?
Not sure I follow. array_upper() is annoying because its semantics
are kinda confusing and idiosyncratic, but that's more the fault of
the type itself than the accessor function. length() and count() are
admittedly very common English words, but it's hard to imagine what
we'd want to use those names for that would be more common/important
than what they're used for already. It's not at all hard to imagine
that with some of the other names that have been proposed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company