Re: JSON Function Bike Shedding - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: JSON Function Bike Shedding
Date
Msg-id CAHyXU0w_c8OFqZ051Y7hs-1KrV681UYoKHEtadACBcfZ5xXnkA@mail.gmail.com
Whole thread Raw
In response to Re: JSON Function Bike Shedding  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: JSON Function Bike Shedding
List pgsql-hackers
On Tue, Feb 19, 2013 at 8:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> The argument for removing json_ prefix is that when function behaviors
>> are unambiguously controlled by the arguments, decorating the function
>> name to match the input argument is unnecessary verbosity.
>
> I've come to value greppability of source code pretty highly.

Hm, good point.  Counter argument: use better editing tools.
Counter-counter argument: postgresql's fast moving boutique syntax is
not well understood by any editor I'm aware of.

The editor I use is Source insight, a $$$ windows tool, and I use it
because it's basically a source code indexer with a full java and C
parser.  It can do SQL also, but it's limited to what you can do with
regex for non fully parsmed languages so if I have the code:

select get(j, '...') from foo;

It doesn't know that j is json and  as such I can't look for all
instances of "get() as pertains to json generally or the json field j"

Interesting aside: another language that is essentially immune to good
tooling, javascript, is exploding in use -- even on the server side.

Anyways, as to overloading in general, well, SQL is heavily
overloaded.  We don't have int_max, float_max, etc. and it would be
usability reduction if we did.  But that's not even the point; the
driving philosophy of SQL is that your data structures (and types) are
to be strongly decoupled from the manipulation you do -- this keeps
the language very general. That philosophy, while not perfect, should
be adhered to when possible.

merlin



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [RFC] indirect toast tuple support
Next
From: Fujii Masao
Date:
Subject: Re: Support for REINDEX CONCURRENTLY