Re: JSON Function Bike Shedding
От | Merlin Moncure |
---|---|
Тема | Re: JSON Function Bike Shedding |
Дата | |
Msg-id | CAHyXU0w_c8OFqZ051Y7hs-1KrV681UYoKHEtadACBcfZ5xXnkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JSON Function Bike Shedding (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: JSON Function Bike Shedding
|
Список | 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 по дате отправления: