On Thu, Feb 21, 2013 at 10:51 AM, Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers