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
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
On Tue, Nov 19, 2013 at 1:43 PM, David Johnston pol...@yahoo.com 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
On 11/20/2013 07:52 AM, Robert Haas wrote:
On Tue, Nov 19, 2013 at 1:43 PM, David Johnston pol...@yahoo.com 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
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 have users who
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 about is that
On Sat, Nov 16, 2013 at 12:32 AM, Josh Berkus j...@agliodbs.com 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
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
On 11/20/2013 12:50 PM, Greg Stark wrote:
On Sat, Nov 16, 2013 at 12:32 AM, Josh Berkus j...@agliodbs.com
mailto:j...@agliodbs.com 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?
David Johnston pol...@yahoo.com 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
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 to
On Wed, Nov 20, 2013 at 12:50 PM, Greg Stark st...@mit.edu 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
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing ha...@2ndquadrant.com 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
On Tue, Nov 19, 2013 at 12:27 PM, David E. Wheeler
da...@justatheory.com wrote:
On Nov 19, 2013, at 8:14 AM, Robert Haas robertmh...@gmail.com 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
On Nov 19, 2013, at 8:14 AM, Robert Haas robertmh...@gmail.com 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
On 11/19/2013 08:14 AM, Robert Haas wrote:
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing ha...@2ndquadrant.com 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,
On Tue, Nov 19, 2013 at 12:59 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/19/2013 08:14 AM, Robert Haas wrote:
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
I am sure you could also devise an json encoding scheme
where white space is significant ;)
I don't
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 ha...@2ndquadrant.com 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
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 duplicate
On 20/11/13 05:14, Robert Haas wrote:
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing ha...@2ndquadrant.com 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
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
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
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
On Tue, Nov 19, 2013 at 11:59 AM, Josh Berkus j...@agliodbs.com wrote:
On 11/19/2013 08:14 AM, Robert Haas wrote:
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
I am sure you could also devise an json encoding scheme
where white space is significant ;)
I don't
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
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
reason I
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
On Sun, Nov 17, 2013 at 10:19 PM, Andrew Dunstan and...@dunslane.net 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
On 11/18/2013 09:38 AM, Merlin Moncure wrote:
On Sun, Nov 17, 2013 at 10:19 PM, Andrew Dunstan and...@dunslane.net 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
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 text
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 as
On Mon, Nov 18, 2013 at 12:10 PM, Josh Berkus j...@agliodbs.com 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
On Nov 16, 2013, at 2:04 PM, Hannu Krosing ha...@2ndquadrant.com 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
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 would stand for
David E. Wheeler da...@justatheory.com 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
On 11/17/2013 09:02 PM, David E. Wheeler wrote:
On Nov 16, 2013, at 2:04 PM, Hannu Krosing ha...@2ndquadrant.com 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
On 11/17/2013 10:51 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@justatheory.com 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
On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine dimi...@2ndquadrant.fr 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
David E. Wheeler da...@justatheory.com writes:
On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine dimi...@2ndquadrant.fr 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
On Nov 17, 2013, at 2:26 PM, Dimitri Fontaine dimi...@2ndquadrant.fr 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
On 11/17/2013 04:51 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@justatheory.com 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
Andrew Dunstan and...@dunslane.net 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
On 18/11/13 09:02, David E. Wheeler wrote:
On Nov 16, 2013, at 2:04 PM, Hannu Krosing ha...@2ndquadrant.com 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
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 just fine
On 11/17/2013 05:44 PM, Dimitri Fontaine wrote:
Andrew Dunstan and...@dunslane.net 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
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
On Nov 17, 2013, at 5:49 PM, Josh Berkus j...@agliodbs.com 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
On 18/11/13 14:51, David E. Wheeler wrote:
On Nov 17, 2013, at 5:49 PM, Josh Berkus j...@agliodbs.com 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
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
On Nov 17, 2013, at 8:19 PM, Andrew Dunstan and...@dunslane.net 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
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 ha...@2ndquadrant.com
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
On Nov 16, 2013, at 12:04 PM, Hannu Krosing ha...@2ndquadrant.com 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,
On 11/16/2013 10:30 PM, David E. Wheeler wrote:
On Nov 16, 2013, at 12:04 PM, Hannu Krosing ha...@2ndquadrant.com 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
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 JSON, and
On Thu, Nov 14, 2013 at 1:54 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 11/14/2013 08:17 PM, Merlin Moncure wrote:
On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler
da...@justatheory.com wrote:
On Nov 14, 2013, at 7:07 AM, Merlin Moncure mmonc...@gmail.com wrote:
This is exactly what
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com 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
On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler da...@justatheory.com wrote:
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com wrote:
Here are the options on the table:
1) convert existing json type to binary flavor (notwithstanding objections)
2) maintain side by side types,
On 11/15/2013 03:25 PM, Merlin Moncure wrote:
On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler da...@justatheory.com wrote:
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com wrote:
Here are the options on the table:
1) convert existing json type to binary flavor
On Fri, Nov 15, 2013 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
On 11/15/2013 03:25 PM, Merlin Moncure wrote:
On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler da...@justatheory.com
wrote:
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com wrote:
Here are the
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
snip long detailed explanation of
On Fri, Nov 15, 2013 at 2:54 PM, Josh Berkus j...@agliodbs.com 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
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 type
On Nov 15, 2013, at 12:37 PM, Andrew Dunstan and...@dunslane.net 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
On 11/15/2013 01:12 PM, David E. Wheeler wrote:
On Nov 15, 2013, at 12:37 PM, Andrew Dunstan and...@dunslane.net 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
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 so. My main
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 would be
k...@rice.edu 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
On 11/15/2013 04:53 PM, Tom Lane wrote:
k...@rice.edu 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
On Nov 15, 2013, at 2:02 PM, Andrew Dunstan and...@dunslane.net 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
On 11/15/2013 09:25 PM, Merlin Moncure wrote:
On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler da...@justatheory.com
wrote:
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com wrote:
Here are the options on the table:
1) convert existing json type to binary flavor
On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing ha...@2ndquadrant.com 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
On 11/15/2013 02:59 PM, Merlin Moncure wrote:
On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing ha...@2ndquadrant.com 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
Josh Berkus wrote
On 11/15/2013 02:59 PM, Merlin Moncure wrote:
On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing lt;
hannu@
gt; 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
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
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
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
On Wed, Nov 13, 2013 at 04:50:49PM -0800, David E. Wheeler wrote:
On Nov 13, 2013, at 4:45 PM, Andrew Dunstan and...@dunslane.net 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
On Wed, Nov 13, 2013 at 6:01 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 11/14/2013 12:09 AM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/13/2013 06:45 AM, Merlin Moncure wrote: I'm not so sure we should
require hstore to do things
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 handles
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 not really
On Thu, Nov 14, 2013 at 9:42 AM, Hannu Krosing ha...@2ndquadrant.com 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
On 11/14/2013 04:07 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 6:01 PM, Hannu Krosing ha...@2ndquadrant.com 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
On 11/14/2013 05:06 PM, Merlin Moncure wrote:
On Thu, Nov 14, 2013 at 9:42 AM, Hannu Krosing ha...@2ndquadrant.com 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
On Thu, Nov 14, 2013 at 10:54 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 11/14/2013 05:06 PM, Merlin Moncure wrote:
On Thu, Nov 14, 2013 at 9:42 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
This is supported by the fact that current functions on json-source
treat it as json-object
On Nov 14, 2013, at 7:07 AM, Merlin Moncure mmonc...@gmail.com 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
On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler
da...@justatheory.com wrote:
On Nov 14, 2013, at 7:07 AM, Merlin Moncure mmonc...@gmail.com 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
On 11/14/2013 08:17 PM, Merlin Moncure wrote:
On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler
da...@justatheory.com wrote:
On Nov 14, 2013, at 7:07 AM, Merlin Moncure mmonc...@gmail.com wrote:
This is exactly what needs to be done, full stop (how about: hstore).
It really comes down to
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
lt;
david@
gt; wrote:
On Nov 14, 2013, at 7:07 AM, Merlin Moncure lt;
mmoncure@
gt; wrote:
This is exactly what needs to be done, full stop (how about: hstore).
It
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/13/2013 02:34 AM, Andrew Dunstan wrote:
If there's agreement on taking these, I will prepare patches and submit
them by the 15th.
With JSON enhancement, my only concern is that there's work ongoing to
integrate
On 11/13/2013 09:45 AM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/13/2013 02:34 AM, Andrew Dunstan wrote:
If there's agreement on taking these, I will prepare patches and submit
them by the 15th.
With JSON enhancement, my only
On Wed, Nov 13, 2013 at 9:32 AM, Andrew Dunstan and...@dunslane.net wrote:
I'm not so sure we should require hstore to do things like build
arbitrary json objects even though I agree that hstore will probably
displace json for must cases where you want to store nested data (as
opposed to
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, I haven't fully
grappled with the coming hstore stuff yet). In
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan and...@dunslane.net 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
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 to
On 11/13/2013 04:58 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan and...@dunslane.net 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
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 and...@dunslane.net
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
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com 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
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com 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
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
coming
On 11/14/2013 12:09 AM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com 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
1 - 100 of 105 matches
Mail list logo
