Robert Haas wrote:
On Sun, Aug 15, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I knew there would be a lot of critters crawling out as soon as we
turned over this rock. Which other data-formats-of-the-week shall
we immortalize as core PG types?
PER-encoded ASN.1, for when
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might
want to consider storing the data in this supposedly more efficient
format, and maybe also some conversion
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might
want to consider storing the data in
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want
On Mon, 2010-08-16 at 11:40 -0400, Christopher Browne wrote:
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient
On 8/16/10 8:40 AM, Christopher Browne wrote:
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haasrobertmh...@gmail.com wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstanand...@dunslane.net writes:
If BSON is simply in effect an efficient
On Sun, Aug 15, 2010 at 11:47 PM, Andrew Dunstan and...@dunslane.net wrote:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might want to
consider storing the data in this supposedly more efficient format,
On 16/08/10 20:17, Joseph Adams wrote:
Also, an idea would be to make json_send and json_recv (binary JSON
send/receive) use BSON rather than JSON-encoded text, as
sending/receiving JSON-encoded text is exactly what text send/receive
do.
The usual reason to use the binary format is
On 8/15/10 8:47 PM, Andrew Dunstan wrote:
On 08/15/2010 11:03 PM, Tom Lane wrote:
Charles Pritchardch...@jumis.com writes:
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client
implementations
Charles Pritchard ch...@jumis.com wrote:
Storing internally as BSON (if it holds up to its premise) would
mean more efficient traversal of internal objects in the future,
if we were to have JSON-related functions/selectors.
How about the fact that not all JSON objects can be represented in
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Charles Pritchard ch...@jumis.com wrote:
Storing internally as BSON (if it holds up to its premise) would
mean more efficient traversal of internal objects in the future,
if we were to have JSON-related functions/selectors.
How about the
1;2403;0cOn Mon, Aug 16, 2010 at 05:02:47PM -0500, Kevin Grittner wrote:
Charles Pritchard ch...@jumis.com wrote:
Storing internally as BSON (if it holds up to its premise) would
mean more efficient traversal of internal objects in the future,
if we were to have JSON-related
On Mon, Aug 16, 2010 at 7:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if it's not just a binary encoding of JSON, I think we can forget
about it ... certainly it won't work in the form I was visualizing.
regards, tom lane
I just read the spec, and BSON has a lot of
but BSON pidgenholes numeric values to either double, int32, int64, or
a 12-byte MongoDB Object ID. Thus, for people who expect JSON to be
able to hold arbitrary-precision numbers (which the JSON data type in
my patch can), using BSON for transfer or storage will violate that
expectation.
On Mon, Aug 16, 2010 at 8:38 PM, Josh Berkus j...@agliodbs.com wrote:
but BSON pidgenholes numeric values to either double, int32, int64, or
a 12-byte MongoDB Object ID. Thus, for people who expect JSON to be
able to hold arbitrary-precision numbers (which the JSON data type in
my patch
Joseph Adams joeyadams3.14...@gmail.com writes:
Others already mentioned that you can't convert 2 billion byte long
JSON strings to BSON. Another issue is that BSON cannot encode all
JSON numbers without precision loss.
As somebody already mentioned, the former isn't likely to be an issue
for
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client implementations
available,
and the format is more efficient than xml and json trees for some use cases.
http://bsonspec.org/
On 8/15/10 11:27
Charles Pritchard ch...@jumis.com writes:
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client implementations
available,
I knew there would be a lot of critters crawling out as soon as we
turned
On 08/15/2010 11:03 PM, Tom Lane wrote:
Charles Pritchardch...@jumis.com writes:
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client implementations
available,
I knew there would be a lot of
On Sun, Aug 15, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Charles Pritchard ch...@jumis.com writes:
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client implementations
available,
I
20 matches
Mail list logo
