Re: json api WIP patch - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: json api WIP patch
Date
Msg-id CAHyXU0zDNzJwkTa=K=oc==aydMwjO4+6rGTgAKTdrW-dicueeg@mail.gmail.com
Whole thread Raw
In response to Re: json api WIP patch  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: json api WIP patch  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 02/04/2013 12:57 PM, Merlin Moncure wrote:
>
>> *) it's bad enough that we drift from sql naming conventions and all
>> type manipulation functions (except in hstore) with type name.
>> json_get etc.   at least using operators allow avoiding some of that
>> unnecessary verbosity.  what's next: text_concatenate('foo', 'bar')?
>>
>
> This names aren't set in stone either. I've been expecting some bikeshedding
> there, and I'm surprised there hasn't been more.

Well -- heh (asked to bikeshed: joy!) -- I felt like my objections
were noted and am more interested in getting said functionality out
the door than splitting hairs over names.  Type prefix issue is under
the same umbrella as use of the -> operator, that is, *not
specifically related to this patch, and not worth holding up this
patch over*.  In both cases it's essentially crying over spilt milk.

My only remaining nit with the proposal is with json_unnest().

SQL unnest() produces list of scalars regardless of dimensionality --
json unnest unwraps one level only (contrast: pl/pgsql array 'slice').So I think 'json_array_each', or perhaps
json_slice()is a better fit
 
there.

merlin



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: proposal: ANSI SQL 2011 syntax for named parameters
Next
From: Will Leinweber
Date:
Subject: Re: json api WIP patch