Re: JSON Function Bike Shedding

On Thu, Feb 21, 2013 at 11:02 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Feb 21, 2013 at 10:51 AM, Merlin Moncure <mmoncure(at)gmail(dot)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.

Well, for case the of operator, it means whatever we reserve to mean.
Very much agree on limitations of symbolic representation of behaviors
(especially since some of the best ones were reserved by SQL or other
acctors), so I think there is growing consensus that such things
should get moved to functions. But functions are a lot less terse
than operators so functions describing clearly defined behaviors are
appreciated.

So, get() means what *define it to mean*, but the definition should be
consistent. If it's shorthand for "get from some multiple key/value
container" then fine. If get() is just not specific enough -- let's
at least try and go for something behavior specific (such as getMember
or some such) before punting and resolving type specific function
names.

In fact, a an awful lot of $propsal's behaviors are in fact direct
proxies for hstore behaviors, and a superficial think is suggesting
that around 90% of hstore API would make sense in JSON terms (even
though Andrew didn't implement all those behaviors and we're not going
to ask him to). That to me is suggesting that tuple manipulation is a
pretty general problem (hstore AKA tuple) and json only brings a
couple of things to the table that isn't already covered there.
Isn't it nice that you can document functions like avals/svals ONCE
and not have to rewrite your triggers when you swap out hstore for
json to get a couple extra behavior bits?

>> 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.

yeah.

merlin