Re: [HACKERS] additional json functionality

Maciej, Thanks for feedback -- it's helpful to get a different perspective on this. > I used to work on a project storing large quantities of schema-less data, > initially using MongoDB, then Postgres with JSON, and eventually I > implemented BSON support for Postgres to get the best of both worl

Re: [HACKERS] additional json functionality

Hi everyone I used to work on a project storing large quantities of schema-less data, initially using MongoDB, then Postgres with JSON, and eventually I implemented BSON support for Postgres to get the best of both worlds: https://github.com/maciekgajewski/postgresbson I don't think that JSONB is

Re: [HACKERS] additional json functionality

On Wed, Nov 20, 2013 at 12:50 PM, Greg Stark wrote: >> For one thing, our storage format is different from theirs (better, >> frankly), and as a result is not compliant with their "standard". > > Not being super familiar with either BSON our JSONB what advantages are we > gaining from the differen

Re: [HACKERS] additional json functionality

On 11/20/2013 01:36 PM, Tom Lane wrote: You'd have to make the data self-identifying (which I think was the plan already), and ensure that *every* function taking "json" could cope with both formats on input. The typmod could only be expected to be enforced when storing or explicitly casting t

Re: [HACKERS] additional json functionality

David Johnston writes: >> On 11/18/2013 06:13 AM, Peter Eisentraut wrote: >>> We could do something like SQL/XML and specify the level of "validity" >>> in a typmod, e.g., json(loose), json(strict), etc. > Three things: > 1) How would this work in the face of functions that erase typemod > infor

Re: [HACKERS] additional json functionality

On 11/20/2013 12:50 PM, Greg Stark wrote: On Sat, Nov 16, 2013 at 12:32 AM, Josh Berkus > wrote: On 11/15/2013 04:00 PM, David Johnston wrote: > Looking at this a different way: could we just implement BSON and leave json > alone? > > http://b

Re: [HACKERS] additional json functionality

On 11/20/2013 04:52 AM, Robert Haas wrote: > I confess to being a bit perplexed by why we want hstore and json to > share a common binary format. hstore doesn't store hierarchical data; > json does. If we design a binary format for json, doesn't that just > obsolete store? Why go to a lot of tro

Re: [HACKERS] additional json functionality

On Sat, Nov 16, 2013 at 12:32 AM, Josh Berkus wrote: > On 11/15/2013 04:00 PM, David Johnston wrote: > > Looking at this a different way: could we just implement BSON and leave > json > > alone? > > > > http://bsonspec.org/ > > In short? No. > > For one thing, our storage format is different fro

Re: [HACKERS] additional json functionality

Hannu Krosing-3 wrote > On 11/18/2013 06:49 PM, Josh Berkus wrote: >> On 11/18/2013 06:13 AM, Peter Eisentraut wrote: >>> On 11/15/13, 6:15 PM, Josh Berkus wrote: Thing is, I'm not particularly concerned about *Merlin's* specific use case, which there are ways around. What I am concerned

Re: [HACKERS] additional json functionality

On 11/18/2013 06:49 PM, Josh Berkus wrote: > On 11/18/2013 06:13 AM, Peter Eisentraut wrote: >> On 11/15/13, 6:15 PM, Josh Berkus wrote: >>> Thing is, I'm not particularly concerned about *Merlin's* specific use >>> case, which there are ways around. What I am concerned about is that we >>> may hav

Re: [HACKERS] additional json functionality

On 11/20/2013 07:52 AM, Robert Haas wrote: On Tue, Nov 19, 2013 at 1:43 PM, David Johnston wrote: IMO A reasonable default cast function should error if the json contents require anything more than a straight parse to be stored into jsonb. If the user still needs to make the conversion we sho

Re: [HACKERS] additional json functionality

On Tue, Nov 19, 2013 at 1:43 PM, David Johnston wrote: > IMO A reasonable default cast function should error if the json contents > require anything more than a straight parse to be stored into jsonb. If the > user still needs to make the conversion we should have a standard and > configurable pa

Re: [HACKERS] additional json functionality

On 11/19/2013 03:06 PM, Merlin Moncure wrote: Therefore I am interested only in supporting two: a) the legacy behavior from 9.2 and 9.3 so we don't destroy people's I'm uncomfortable with the word 'legacy'. This suggests the new type will essentially deprecate the old type. "Existing"

Re: [HACKERS] additional json functionality

On Tue, Nov 19, 2013 at 11:59 AM, Josh Berkus wrote: > On 11/19/2013 08:14 AM, Robert Haas wrote: >> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote: >>> I am sure you could also devise an json encoding scheme >>> where white space is significant ;) >> >> I don't even have to think hard. If

Re: [HACKERS] additional json functionality

On 11/19/2013 01:43 PM, David Johnston wrote: I have not really pondered storing scalars into jsonb but before pondering usability are there any technical concerns. If the goal is to share the backend with hstore then current hstore does not allow for this and so the json aspect would either

Re: [HACKERS] additional json functionality

Gavin Flower-2 wrote > More seriously, there are obviously variants in what people consider > useful human readable form of JSON output, but it is probably > inefficient to store white space. Enough to matter? Maybe the extra whitespace causes a marginal value to be toasted but, IIUC, for a v

Re: [HACKERS] additional json functionality

On 11/19/2013 01:43 PM, David Johnston wrote: Andrew Dunstan wrote Given that, I'm not sure we shouldn't permit them in b) either. I think I lost that argument back in the 9.2 dev cycle. I really don't want to get to a situation where foo::json::jsonb can produce an error. So what do you propo

Re: [HACKERS] additional json functionality

On 20/11/13 05:14, Robert Haas wrote: On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote: I am sure you could also devise an json encoding scheme where white space is significant ;) I don't even have to think hard. If you want your JSON to be human-readable, it's entirely possible that you

Re: [HACKERS] additional json functionality

Andrew Dunstan wrote > Given that, I'm not sure we shouldn't permit them in b) either. I think > I lost that argument back in the 9.2 dev cycle. I really don't want to > get to a situation where foo::json::jsonb can produce an error. So what do you propose happens when the input json has duplica

Re: [HACKERS] additional json functionality

On 11/19/2013 12:59 PM, Josh Berkus wrote: On 11/19/2013 08:14 AM, Robert Haas wrote: On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote: I am sure you could also devise an json encoding scheme where white space is significant ;) I don't even have to think hard. If you want your JSON to b

Re: [HACKERS] additional json functionality

On Tue, Nov 19, 2013 at 12:59 PM, Josh Berkus wrote: > On 11/19/2013 08:14 AM, Robert Haas wrote: >> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote: >>> I am sure you could also devise an json encoding scheme >>> where white space is significant ;) >> >> I don't even have to think hard. If

Re: [HACKERS] additional json functionality

On 11/19/2013 08:14 AM, Robert Haas wrote: > On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote: >> I am sure you could also devise an json encoding scheme >> where white space is significant ;) > > I don't even have to think hard. If you want your JSON to be > human-readable, it's entirely po

Re: [HACKERS] additional json functionality

On Nov 19, 2013, at 8:14 AM, Robert Haas wrote: > Everyone on this thread who thinks that there is Only One Right Way To > Do It should take a chill pill. There is, in fact, more than one > right way to do it. You shoulda been a Perl hacker, Robert. D -- Sent via pgsql-hackers mailing list

Re: [HACKERS] additional json functionality

On Tue, Nov 19, 2013 at 12:27 PM, David E. Wheeler wrote: > On Nov 19, 2013, at 8:14 AM, Robert Haas wrote: >> Everyone on this thread who thinks that there is Only One Right Way To >> Do It should take a chill pill. There is, in fact, more than one >> right way to do it. > > You shoulda been a

Re: [HACKERS] additional json functionality

On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote: > I am sure you could also devise an json encoding scheme > where white space is significant ;) I don't even have to think hard. If you want your JSON to be human-readable, it's entirely possible that you want it stored using the same whitesp

Re: [HACKERS] additional json functionality

On Mon, Nov 18, 2013 at 12:10 PM, Josh Berkus wrote: > Merlin, > >> *) Aside from the text in and out routines, how is 'jsbonb' different >> from the coming 'nested hstore'? Enough to justify two code bases? > > In/out functions and defaults are all different. Otherwise, the two > types will be

Re: [HACKERS] additional json functionality

Merlin, > *) Aside from the text in and out routines, how is 'jsbonb' different > from the coming 'nested hstore'? Enough to justify two code bases? In/out functions and defaults are all different. Otherwise, the two types will be accessing the same code base, so no duplication. Think of is a

Re: [HACKERS] additional json functionality

On 11/18/2013 06:13 AM, Peter Eisentraut wrote: > On 11/15/13, 6:15 PM, Josh Berkus wrote: >> Thing is, I'm not particularly concerned about *Merlin's* specific use >> case, which there are ways around. What I am concerned about is that we >> may have users who have years of data stored in JSON tex

Re: [HACKERS] additional json functionality

On 11/18/2013 09:38 AM, Merlin Moncure wrote: On Sun, Nov 17, 2013 at 10:19 PM, Andrew Dunstan wrote: I don't think any name that doesn't begin with "json" is acceptable. I could live with "jsonb". It has the merit of brevity, but maybe it's a tad too close to "json" to be the right answer. I

Re: [HACKERS] additional json functionality

On Sun, Nov 17, 2013 at 10:19 PM, Andrew Dunstan wrote: > I don't think any name that doesn't begin with "json" is acceptable. I could > live with "jsonb". It has the merit of brevity, but maybe it's a tad too > close to "json" to be the right answer. I think that seems right. Couple thoughts:

Re: [HACKERS] additional json functionality

On 11/15/13, 6:15 PM, Josh Berkus wrote: > Thing is, I'm not particularly concerned about *Merlin's* specific use > case, which there are ways around. What I am concerned about is that we > may have users who have years of data stored in JSON text fields which > won't survive an upgrade to binary J

Re: [HACKERS] additional json functionality

On 11/18/2013 05:19 AM, Andrew Dunstan wrote: > > On 11/17/2013 08:49 PM, Josh Berkus wrote: >>> Now, if it turns out that the new hstore is not dealing with json input >>> and output, we could have json, jstore and hstore. >> Jstore isn't the worst name suggestion I've heard on this thread. The >

Re: [HACKERS] additional json functionality

On Nov 17, 2013, at 8:19 PM, Andrew Dunstan wrote: > I don't think any name that doesn't begin with "json" is acceptable. I could > live with "jsonb". It has the merit of brevity, but maybe it's a tad too > close to "json" to be the right answer. JSONFTW. David -- Sent via pgsql-hackers m

Re: [HACKERS] additional json functionality

On 11/17/2013 08:49 PM, Josh Berkus wrote: Now, if it turns out that the new hstore is not dealing with json input and output, we could have json, jstore and hstore. Jstore isn't the worst name suggestion I've heard on this thread. The reason I prefer JSONB though, is that a new user looking f

Re: [HACKERS] additional json functionality

On 18/11/13 14:51, David E. Wheeler wrote: On Nov 17, 2013, at 5:49 PM, Josh Berkus wrote: Jstore isn't the worst name suggestion I've heard on this thread. The reason I prefer JSONB though, is that a new user looking for a place to put JSON data will clearly realize that JSON and JSONB are a

Re: [HACKERS] additional json functionality

On Nov 17, 2013, at 5:49 PM, Josh Berkus wrote: > Jstore isn't the worst name suggestion I've heard on this thread. The > reason I prefer JSONB though, is that a new user looking for a place to > put JSON data will clearly realize that JSON and JSONB are alternatives > and related in some way.

Re: [HACKERS] additional json functionality

> Now, if it turns out that the new hstore is not dealing with json input > and output, we could have json, jstore and hstore. Jstore isn't the worst name suggestion I've heard on this thread. The reason I prefer JSONB though, is that a new user looking for a place to put JSON data will clearly

Re: [HACKERS] additional json functionality

On 11/17/2013 05:44 PM, Dimitri Fontaine wrote: Andrew Dunstan writes: That would be one of the silliest and most short-sighted decisions we have made in many years, IMNSHO. The demand for strong JSON support is enormous. One of the silliest and most short-sighted decisions we made recently m

Re: [HACKERS] additional json functionality

On 18/11/13 09:45, David Johnston wrote: David E. Wheeler-3 wrote I like JSONB because: 1. The "B" means "binary" 2. The "B" means "second" 3. It's short 4. See also BYTEA. "json_strict" : Not sure about the "bytea" reference off-hand... I was pondering "jsons" which meets the short property

Re: [HACKERS] additional json functionality

On 18/11/13 09:02, David E. Wheeler wrote: On Nov 16, 2013, at 2:04 PM, Hannu Krosing wrote: It’s still input and output as JSON, though. Yes, because JavaScript Object Notation *is* a serialization format (aka Notation) for converting JavaScript Objects to text format and back :) I still li

Re: [HACKERS] additional json functionality

Andrew Dunstan writes: > That would be one of the silliest and most short-sighted decisions we have > made in many years, IMNSHO. The demand for strong JSON support is enormous. One of the silliest and most short-sighted decisions we made recently might have been to actually ship that json varian

Re: [HACKERS] additional json functionality

On 11/17/2013 04:51 PM, Dimitri Fontaine wrote: "David E. Wheeler" writes: You know that both types support scalar values right? 'a'::JSON works now, and 'a'::hstore works with the WIP patch. For that reason I would not think that "doc" or "obj" would be good choices. I'm wondering about just

Re: [HACKERS] additional json functionality

On Nov 17, 2013, at 2:26 PM, Dimitri Fontaine wrote: >> It’s syntax is different than JSON, so one would need to convert to >> and from JSON all the time to parse and serialize. PITA. > > Oh I misremembered about that, I though it would take JSON as input > as-is and could be made to output JSON

Re: [HACKERS] additional json functionality

"David E. Wheeler" writes: > On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine wrote: >> I'm wondering about just pushing hstore in core (even if technically >> still an extension, install it by default, like we do for PLpgSQL), and >> calling it a day. > > It’s syntax is different than JSON, so one

Re: [HACKERS] additional json functionality

On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine wrote: > I'm wondering about just pushing hstore in core (even if technically > still an extension, install it by default, like we do for PLpgSQL), and > calling it a day. It’s syntax is different than JSON, so one would need to convert to and from

Re: [HACKERS] additional json functionality

On 11/17/2013 10:51 PM, Dimitri Fontaine wrote: > "David E. Wheeler" writes: >> You know that both types support scalar values right? 'a'::JSON works now, >> and 'a'::hstore works with the WIP patch. For that reason I would not think >> that "doc" or "obj" would be good choices. > I'm wondering ab

Re: [HACKERS] additional json functionality

On 11/17/2013 09:02 PM, David E. Wheeler wrote: > On Nov 16, 2013, at 2:04 PM, Hannu Krosing wrote: > >>> It’s still input and output as JSON, though. >> Yes, because JavaScript Object Notation *is* a serialization format >> (aka Notation) for converting JavaScript Objects to text format >> and ba

Re: [HACKERS] additional json functionality

"David E. Wheeler" writes: > You know that both types support scalar values right? 'a'::JSON works now, > and 'a'::hstore works with the WIP patch. For that reason I would not think > that "doc" or "obj" would be good choices. I'm wondering about just pushing hstore in core (even if technically s

Re: [HACKERS] additional json functionality

David E. Wheeler-3 wrote > I like JSONB because: > > 1. The "B" means "binary" > 2. The "B" means "second" > 3. It's short > 4. See also BYTEA. "json_strict" : Not sure about the "bytea" reference off-hand... I was pondering "jsons" which meets the short property just fine and the trailing "s"

Re: [HACKERS] additional json functionality

On Nov 16, 2013, at 2:04 PM, Hannu Krosing wrote: >> It’s still input and output as JSON, though. > Yes, because JavaScript Object Notation *is* a serialization format > (aka Notation) for converting JavaScript Objects to text format > and back :) >> I still like JSONB best. > To me it feels redu

Re: [HACKERS] additional json functionality

On 11/16/2013 02:04 PM, Hannu Krosing wrote: > On 11/16/2013 10:30 PM, David E. Wheeler wrote: >> I still like JSONB best. > To me it feels redundant, like binarytextbinary > > the binary representation of JSON is JavaScript(-like) Object, not > "binary json" JSONB is as close as we can get to "

Re: [HACKERS] additional json functionality

On 11/16/2013 10:30 PM, David E. Wheeler wrote: > On Nov 16, 2013, at 12:04 PM, Hannu Krosing wrote: > >> Then perhaps name the "new binary json" as jsob (JavaScript Object Binary) >> or just jsobj (JavaScript Object) and keep current json for what it is, >> namely >> JavaScript Object Notation. >

Re: [HACKERS] additional json functionality

On Nov 16, 2013, at 12:04 PM, Hannu Krosing wrote: > Then perhaps name the "new binary json" as jsob (JavaScript Object Binary) > or just jsobj (JavaScript Object) and keep current json for what it is, > namely > JavaScript Object Notation. It’s still input and output as JSON, though. I still l

Re: [HACKERS] additional json functionality

On 11/16/2013 12:15 AM, Josh Berkus wrote: > On 11/15/2013 02:59 PM, Merlin Moncure wrote: >> On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing >> wrote: >> I think you may be on to something here. This might also be a way >> opt-in to fast(er) serialization (upthread it was noted this is >> unimp

Re: [HACKERS] additional json functionality

On 11/15/2013 07:32 PM, Josh Berkus wrote: On 11/15/2013 04:00 PM, David Johnston wrote: Looking at this a different way: could we just implement BSON and leave json alone? http://bsonspec.org/ In short? No. For one thing, our storage format is different from theirs (better, frankly), and a

Re: [HACKERS] additional json functionality

On 11/15/2013 04:00 PM, David Johnston wrote: > Looking at this a different way: could we just implement BSON and leave json > alone? > > http://bsonspec.org/ In short? No. For one thing, our storage format is different from theirs (better, frankly), and as a result is not compliant with their

Re: [HACKERS] additional json functionality

Looking at this a different way: could we just implement BSON and leave json alone? http://bsonspec.org/ David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/additional-json-functionality-tp5777975p5778656.html Sent from the PostgreSQL - hackers mailing list arc

Re: [HACKERS] additional json functionality

Josh Berkus wrote > On 11/15/2013 02:59 PM, Merlin Moncure wrote: >> On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing < > hannu@ > > wrote: >> I think you may be on to something here. This might also be a way >> opt-in to fast(er) serialization (upthread it was noted this is >> unimportant; I'm s

Re: [HACKERS] additional json functionality

On 11/15/2013 02:59 PM, Merlin Moncure wrote: > On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing wrote: > I think you may be on to something here. This might also be a way > opt-in to fast(er) serialization (upthread it was noted this is > unimportant; I'm skeptical). I deeply feel that two types

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing wrote: I think we need to take a *very* hard look at #3 before exploring #1 or #2: Haven't through it through yet but it may be possible to handle this in such a way that will be mostly transparent to the end user and may have oth

Re: [HACKERS] additional json functionality

On 11/15/2013 09:25 PM, Merlin Moncure wrote: > On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler > wrote: >> On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: >> >>> Here are the options on the table: >>> 1) convert existing json type to binary flavor (notwithstanding objections) >>> 2) mainta

Re: [HACKERS] additional json functionality

On Nov 15, 2013, at 2:02 PM, Andrew Dunstan wrote: > Yeah, it would be a total foot gun here I think. > > I've come to the conclusion that the only possible solution is to have a > separate type. That's a bit sad, but there it is. The upside is that this > will make the work Teodor has mention

Re: [HACKERS] additional json functionality

On 11/15/2013 04:53 PM, Tom Lane wrote: "k...@rice.edu" writes: On Fri, Nov 15, 2013 at 01:18:22PM -0800, Josh Berkus wrote: I believe this was a danger we recognized when we added the JSON type, including the possibility that a future binary type might need to be a separate type due to compa

Re: [HACKERS] additional json functionality

"k...@rice.edu" writes: > On Fri, Nov 15, 2013 at 01:18:22PM -0800, Josh Berkus wrote: >> I believe this was a danger we recognized when we added the JSON type, >> including the possibility that a future binary type might need to be a >> separate type due to compatibility issues. The only sad thi

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 01:18:22PM -0800, Josh Berkus wrote: > > I believe this was a danger we recognized when we added the JSON type, > including the possibility that a future binary type might need to be a > separate type due to compatibility issues. The only sad thing is the > naming; it woul

Re: [HACKERS] additional json functionality

Merlin Moncure-2 wrote >> I don't want to have two types, but I think I'd probably rather have two >> clean types than this. I can't imagine it being remotely acceptable to >> have >> behaviour depend in whether or not something was ever stored, which is >> what >> this looks like. > > Well, maybe

Re: [HACKERS] additional json functionality

On 11/15/2013 01:12 PM, David E. Wheeler wrote: > On Nov 15, 2013, at 12:37 PM, Andrew Dunstan wrote: > >> It's making my head hurt, to be honest, and it sounds like a recipe for >> years and years of inconsistencies and bugs. >> >> I don't want to have two types, but I think I'd probably rather

Re: [HACKERS] additional json functionality

On Nov 15, 2013, at 12:37 PM, Andrew Dunstan wrote: > It's making my head hurt, to be honest, and it sounds like a recipe for years > and years of inconsistencies and bugs. > > I don't want to have two types, but I think I'd probably rather have two > clean types than this. I can't imagine it

Re: [HACKERS] additional json functionality

On 2013-11-15 12:54:53 -0800, Josh Berkus wrote: > On 11/15/2013 12:25 PM, Merlin Moncure wrote: > > Kinda yes, kinda no. Here's a rough sketch of what I'm thinking: > > > > *) 'json' type internally has a binary as well a text representation. > > The text representation is basically the current

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 2:54 PM, Josh Berkus wrote: > On 11/15/2013 12:25 PM, Merlin Moncure wrote: >> Kinda yes, kinda no. Here's a rough sketch of what I'm thinking: >> >> *) 'json' type internally has a binary as well a text representation. >> The text representation is basically the current t

Re: [HACKERS] additional json functionality

On 11/15/2013 12:25 PM, Merlin Moncure wrote: > Kinda yes, kinda no. Here's a rough sketch of what I'm thinking: > > *) 'json' type internally has a binary as well a text representation. > The text representation is basically the current type behavior That's not at all workable. Users would b

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 2:37 PM, Andrew Dunstan wrote: > > On 11/15/2013 03:25 PM, Merlin Moncure wrote: >> >> On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler >> wrote: >>> >>> On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: >>> Here are the options on the table: 1) convert existi

Re: [HACKERS] additional json functionality

On 11/15/2013 03:25 PM, Merlin Moncure wrote: On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler wrote: On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: Here are the options on the table: 1) convert existing json type to binary flavor (notwithstanding objections) 2) maintain side by side t

Re: [HACKERS] additional json functionality

On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler wrote: > On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: > >> Here are the options on the table: >> 1) convert existing json type to binary flavor (notwithstanding objections) >> 2) maintain side by side types, one representing binary, one text

Re: [HACKERS] additional json functionality

On Nov 15, 2013, at 6:35 AM, Merlin Moncure wrote: > Here are the options on the table: > 1) convert existing json type to binary flavor (notwithstanding objections) > 2) maintain side by side types, one representing binary, one text. > unfortunately, i think the text one must get the name 'json'

Re: [HACKERS] additional json functionality

On Thu, Nov 14, 2013 at 1:54 PM, Hannu Krosing wrote: > On 11/14/2013 08:17 PM, Merlin Moncure wrote: >> On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler >> wrote: >>> On Nov 14, 2013, at 7:07 AM, Merlin Moncure wrote: >>> This is exactly what needs to be done, full stop (how about: hstor

Re: [HACKERS] additional json functionality

Hannu Krosing-5 wrote > On 11/14/2013 08:17 PM, Merlin Moncure wrote: >> On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler >> < > david@ > > wrote: >>> On Nov 14, 2013, at 7:07 AM, Merlin Moncure < > mmoncure@ > > wrote: >>> This is exactly what needs to be done, full stop (how about: hst

Re: [HACKERS] additional json functionality

On 11/14/2013 08:17 PM, Merlin Moncure wrote: > On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler > wrote: >> On Nov 14, 2013, at 7:07 AM, Merlin Moncure wrote: >> >>> This is exactly what needs to be done, full stop (how about: hstore). >>> It really comes down to this: changing the serializati

Re: [HACKERS] additional json functionality

On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler wrote: > On Nov 14, 2013, at 7:07 AM, Merlin Moncure wrote: > >> This is exactly what needs to be done, full stop (how about: hstore). >> It really comes down to this: changing the serialization behaviors >> that have been in production for 2 rel

Re: [HACKERS] additional json functionality

On Nov 14, 2013, at 7:07 AM, Merlin Moncure wrote: > This is exactly what needs to be done, full stop (how about: hstore). > It really comes down to this: changing the serialization behaviors > that have been in production for 2 releases (three if you count the > extension) is bad enough, but mak

Re: [HACKERS] additional json functionality

On Thu, Nov 14, 2013 at 10:54 AM, Hannu Krosing wrote: > On 11/14/2013 05:06 PM, Merlin Moncure wrote: >> On Thu, Nov 14, 2013 at 9:42 AM, Hannu Krosing wrote: >>> This is supported by the fact that current functions on json-source >>> treat it as json-object (for example key lookup gives you the

Re: [HACKERS] additional json functionality

On 11/14/2013 05:06 PM, Merlin Moncure wrote: > On Thu, Nov 14, 2013 at 9:42 AM, Hannu Krosing wrote: >> This is supported by the fact that current functions on json-source >> treat it as json-object (for example key lookup gives you the value >> of latest key and not a list of all matching key va

Re: [HACKERS] additional json functionality

On 11/14/2013 04:07 PM, Merlin Moncure wrote: > On Wed, Nov 13, 2013 at 6:01 PM, Hannu Krosing wrote: >> >> I guess we should not replace current JSON type with hstore based >> one, but add something json-like based on nested hstore instead. >> >> Maybe call it jsdoc or jdoc or jsobj or somesuch.

Re: [HACKERS] additional json functionality

On Thu, Nov 14, 2013 at 9:42 AM, Hannu Krosing wrote: > This is supported by the fact that current functions on json-source > treat it as json-object (for example key lookup gives you the value > of latest key and not a list of all matching key values). yeah. hm. that's a good point. Maybe there

Re: [HACKERS] additional json functionality

On 11/14/2013 12:20 AM, Josh Berkus wrote: > Merlin, > > >> I use pg/JSON all over the place. In several cases I have to create >> documents with ordered keys because the parser on the other side wants >> them that way -- this is not a hypothetical argument. The current >> json serialization API

Re: [HACKERS] additional json functionality

On 11/14/2013 01:42 AM, Andrew Dunstan wrote: > > On 11/13/2013 07:01 PM, Hannu Krosing wrote: >> >> I guess we should not replace current JSON type with hstore based >> one, but add something json-like based on nested hstore instead. > > > Well, that's two voices for that course of action. I am no

Re: [HACKERS] additional json functionality

On Wed, Nov 13, 2013 at 6:01 PM, Hannu Krosing wrote: > On 11/14/2013 12:09 AM, Merlin Moncure wrote: >> On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus wrote: >>> On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should >>> require hstore to do things like build Also, json_obje

Re: [HACKERS] additional json functionality

On Wed, Nov 13, 2013 at 04:50:49PM -0800, David E. Wheeler wrote: > On Nov 13, 2013, at 4:45 PM, Andrew Dunstan wrote: > > >> It should be a pretty-printing function option, perhaps, but not core to > >> the type itself, IMO. > > > > I don't in the least understand how it could be a pretty prin

Re: [HACKERS] additional json functionality

On Nov 13, 2013, at 4:45 PM, Andrew Dunstan wrote: >> It should be a pretty-printing function option, perhaps, but not core to the >> type itself, IMO. > > I don't in the least understand how it could be a pretty printing option. If > we move to a binary rep using the hstore stuff order will b

Re: [HACKERS] additional json functionality

On 11/13/2013 07:39 PM, David E. Wheeler wrote: On Nov 13, 2013, at 2:41 PM, Gavin Flower wrote: Would be possible to have a boolean, such as 'strict' - so that unique & ordered was only imposed when strict was TRUE? Alternately, separate functions to allow the same choice? It should be a

Re: [HACKERS] additional json functionality

On 11/13/2013 07:01 PM, Hannu Krosing wrote: I guess we should not replace current JSON type with hstore based one, but add something json-like based on nested hstore instead. Well, that's two voices for that course of action. Interesting that I don't think I heard a single voice for this e

Re: [HACKERS] additional json functionality

On Nov 13, 2013, at 2:41 PM, Gavin Flower wrote: > Would be possible to have a boolean, such as 'strict' - so that unique & > ordered was only imposed when strict was TRUE? Alternately, separate > functions to allow the same choice? It should be a pretty-printing function option, perhaps, but

Re: [HACKERS] additional json functionality

On 11/14/2013 12:09 AM, Merlin Moncure wrote: > On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus wrote: >> On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should >> require hstore to do things like build >>> Also, json_object is pretty weird to me, I'm not sure I see the >>> advantag

Re: [HACKERS] additional json functionality

Merlin, > I use pg/JSON all over the place. In several cases I have to create > documents with ordered keys because the parser on the other side wants > them that way -- this is not a hypothetical argument. The current > json serialization API handles that just fine and the hstore stuff > comin

Re: [HACKERS] additional json functionality

​ On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus wrote: > > > Putting it all together, I'd consider: > > *) dropping json_object (although maybe there is a case I'm not > thinking about) > > *) changing json_build function names to get the json prefix > > *) adding a json object constructor that t

Re: [HACKERS] additional json functionality

On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus wrote: > On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should > require hstore to do things like build >> Also, json_object is pretty weird to me, I'm not sure I see the >> advantage of a new serialization format, and I don't agree w

Re: [HACKERS] additional json functionality

On 14/11/13 11:33, Andrew Dunstan wrote: On 11/13/2013 04:58 PM, Merlin Moncure wrote: On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan wrote: On 11/13/2013 11:37 AM, Merlin Moncure wrote: Yes. and I think this is one of the major advantages of the json API vs hstore: you can serialize objec

Re: [HACKERS] additional json functionality

On 11/13/2013 04:58 PM, Merlin Moncure wrote: On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan wrote: On 11/13/2013 11:37 AM, Merlin Moncure wrote: Yes. and I think this is one of the major advantages of the json API vs hstore: you can serialize objects that hstore cannot -- at least not with

Re: [HACKERS] additional json functionality

On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should require hstore to do things like build > Also, json_object is pretty weird to me, I'm not sure I see the > advantage of a new serialization format, and I don't agree with the > statement "but it is the caller's reponsibility t

Re: [HACKERS] additional json functionality

On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan wrote: > On 11/13/2013 11:37 AM, Merlin Moncure wrote: >> >> Yes. and I think this is one of the major advantages of the json API >> vs hstore: you can serialize objects that hstore cannot -- at least >> not without extra scaffolding (at least, AIUI

  1   2   >