2010/1/4 David E. Wheeler da...@kineticode.com:
On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote:
That sounds good and seems possible, as far as operator returns JSON
always. Perhaps every JSON fetching returns JSON even if the result
would be a number. You can cast it.
% SELECT
On Sun, Jan 3, 2010 at 1:51 PM, David E. Wheeler da...@kineticode.com wrote:
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
I think the minimal functionality I'd want is:
convert record to JSON
convert JSON to record
With caveats as to dealing with nested structures (can a record be
On Jan 4, 2010, at 8:18 PM, Robert Haas wrote:
Is this something you are planning to work on for the 2010-01-15
CommitFest? If not, I think we should go ahead and mark the patch
which was the original subject of this thread Returned with
Feedback, as it does not seem to make sense to add it
Hitoshi Harada wrote:
2010/1/3 Andrew Dunstan and...@dunslane.net:
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
I think the minimal functionality I'd want is:
convert record to JSON
convert JSON to record
With caveats as to dealing with nested structures (can a record be an attribute
of a record?).
extract a value, or set of values, from JSON
David E. Wheeler wrote:
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
I think the minimal functionality I'd want is:
convert record to JSON
convert JSON to record
With caveats as to dealing with nested structures (can a record be an attribute
of a record?).
We allow
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
Cool, that sounds right.
OK, but hstores are flat, unlike JSON. We need some way to
2010/1/4 David E. Wheeler da...@kineticode.com:
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
Cool, that sounds right.
Does it
Hitoshi Harada wrote:
2010/1/4 David E. Wheeler da...@kineticode.com:
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote:
That sounds good and seems possible, as far as operator returns JSON
always. Perhaps every JSON fetching returns JSON even if the result
would be a number. You can cast it.
% SELECT ('{foo:{bar:[a,b,c]}}' - '[foo][1]')::text;
1
On Sun, Jan 3, 2010 at 11:00 AM, Andrew Dunstan and...@dunslane.net wrote:
Hitoshi Harada wrote:
2010/1/3 Andrew Dunstan and...@dunslane.net:
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote:
Mine for one :-). Quite apart from any other reason I would expect it to
make indexing parts of the JSON more tractable. Say we use it to store a
web session object, which is a natural enough use. I might well want to
find or modify
2010/1/3 Peter Eisentraut pete...@gmx.net:
On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote:
Mine for one :-). Quite apart from any other reason I would expect it to
make indexing parts of the JSON more tractable. Say we use it to store a
web session object, which is a natural enough
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already invented? This
is what shared libraries are all about.
cheers
andrew
--
Sent
2010/1/3 Andrew Dunstan and...@dunslane.net:
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already invented? This is
what shared
Andrew Dunstan and...@dunslane.net writes:
Does anyone have any real-world experience with any of the JSON C libraries?
I do not, but I see that YAJL http://lloyd.github.com/yajl/ is now in
Fedora, and has a BSDish license
It's there in debian too, unstable and testing, and should be there on
On tor, 2009-12-31 at 11:12 -0500, Andrew Dunstan wrote:
David E. Wheeler wrote:
On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote:
I think the primary use will be to load a JSON value into Perl or Python
and process it there. So a json type that doesn't have any interesting
Peter Eisentraut wrote:
IMNSHO it's essential. I think Peter's approach of ignoring this
requirement is extremely shortsighted.
Whose requirement is it? I'm not ignoring it, but so far no one has
actually said that it is a requirement and why.
Mine for one :-). Quite apart from
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
Whose requirement is it? I'm not ignoring it, but so far no one has
actually said that it is a requirement and why.
Mine for one :-).
I think there are a couple of interacting factors here. We are not
likely to want to go
On ons, 2009-12-30 at 12:53 -0500, Robert Haas wrote:
It looks like they are all very permissive, though I wonder what the
legal effect of a license clause that the software be used for Good
and not Evil might be.
It's not without issues, apparently:
On ons, 2009-12-30 at 13:23 -0500, Andrew Dunstan wrote:
I'd like to see at
least the outline of an API before we go any further. JSON is, shall
we
say, lightly specified, and doesn't appear to have any equivalent to
XPath and friends, for example. How will we extract values from a
JSON
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Doesn't seem insurmountable, though, just one more thing to think
about as we're having this conversation. Someone else will need to
weigh in on this point though, as I don't use JSON in a way that would
make anything beyond validation
On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote:
I think the primary use will be to load a JSON value into Perl or Python
and process it there. So a json type that doesn't have any interesting
operators doesn't sound useless to me. The features I would like to get
out of it are input
David E. Wheeler wrote:
On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote:
I think the primary use will be to load a JSON value into Perl or Python
and process it there. So a json type that doesn't have any interesting
operators doesn't sound useless to me. The features I would like
On Thu, Dec 31, 2009 at 11:12 AM, Andrew Dunstan and...@dunslane.net wrote:
David E. Wheeler wrote:
On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote:
I think the primary use will be to load a JSON value into Perl or Python
and process it there. So a json type that doesn't have any
Robert Haas wrote:
Anyhow, that brings me back to the question I asked upthread, which is
Can/should we suck one of these libraries into our code base (and if
so, which?) or do we need to add an analogue of --with-libxml so that
we can link against an external library if present and omit the
Robert Haas robertmh...@gmail.com writes:
Anyhow, that brings me back to the question I asked upthread, which is
Can/should we suck one of these libraries into our code base (and if
so, which?) or do we need to add an analogue of --with-libxml so that
we can link against an external library if
On Thu, Dec 31, 2009 at 5:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Anyhow, that brings me back to the question I asked upthread, which is
Can/should we suck one of these libraries into our code base (and if
so, which?) or do we need to add an analogue
On Dec 29, 2009, at 6:14 PM, Robert Haas wrote:
I've been mulling this over and I think this is a pretty good idea.
If we could get it done in time for 8.5, we could actually change the
output type of EXPLAIN (FORMAT JSON) to the new type. If not, I'm
inclined to say that we should postpone
On Wed, Dec 30, 2009 at 12:38 PM, David E. Wheeler da...@kineticode.com wrote:
On Dec 29, 2009, at 6:14 PM, Robert Haas wrote:
I've been mulling this over and I think this is a pretty good idea.
If we could get it done in time for 8.5, we could actually change the
output type of EXPLAIN
On Dec 30, 2009, at 9:53 AM, Robert Haas wrote:
It looks like they are all very permissive, though I wonder what the
legal effect of a license clause that the software be used for Good
and not Evil might be.
Yeah, that might be too restrictive, given that PostgreSQL is used by
government
David E. Wheeler wrote:
I guess the question is whether we would slurp one of these into our
code base, or whether we would add an analog of --with-libxml and
provide only a stub implementation when the library is not present.
Any opinions? Does anyone know whether any of these
On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan and...@dunslane.net wrote:
I think we are getting the cart way before the horse. I'd like to see at
least the outline of an API before we go any further. JSON is, shall we say,
lightly specified, and doesn't appear to have any equivalent to XPath
Robert Haas wrote:
On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan and...@dunslane.net wrote:
I think we are getting the cart way before the horse. I'd like to see at
least the outline of an API before we go any further. JSON is, shall we say,
lightly specified, and doesn't appear to have
On Wed, Dec 30, 2009 at 2:26 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan and...@dunslane.net
wrote:
I think we are getting the cart way before the horse. I'd like to see at
least the outline of an API before we go any
On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type
On ons, 2009-12-16 at 11:28 -0800, David E. Wheeler wrote:
I just realized that this was easy to do, and despite my complete lack of C
skillz was able to throw this together in a couple of hours. It might be
handy to some, though the possible downsides are:
* No json_to_hstore().
* Leads
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with json as text?
json_data_type++
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with json as text?
json_data_type++
What would that do for us?
On Dec 18, 2009, at 8:51 AM, Robert Haas wrote:
What would that do for us?
I'm not opposed to it, but it seems like the more important thing
would be to provide functions or operators that can do things like
extract an array, extract a hash key, identify whether something is a
hash, list,
Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with json as text?
Andrew Dunstan and...@dunslane.net writes:
You're correct that we don't necessarily need a new type, we could just
make it text and have a bunch of operations, but that seems to violate
the principle of data type abstraction a bit.
I think the relevant precedent is that we have an xml type.
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
You're correct that we don't necessarily need a new type, we could just
make it text and have a bunch of operations, but that seems to violate
the principle of data type abstraction a bit.
I think the relevant precedent is
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
You're correct that we don't necessarily need a new type, we could just
make it text and have a bunch of operations, but that seems to violate
the principle of data type abstraction a bit.
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
[ I can already hear somebody insisting on a yaml type :-( ]
Now that's a case where I think a couple of converter functions at most
should meet the need.
Well, actually, now that you mention it: how much of a json type would
be
Tom Lane escribió:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
[ I can already hear somebody insisting on a yaml type :-( ]
Now that's a case where I think a couple of converter functions at most
should meet the need.
Well, actually, now that you mention it: how much
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Well, actually, now that you mention it: how much of a json type would
be duplicative of the xml stuff? Would it be sufficient to provide
json - xml converters and let the latter type do all the heavy lifting?
(If so, this
On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Well, actually, now that you mention it: how much of a json type would
be duplicative of the xml stuff? Would it be sufficient to provide
json - xml
+1 for such a feature, simply to avoid the need of
writing a hstore-parser (which wasn't too bad
to write, but it felt unnecessary). Doesn't
matter to me if it's hstore-to-json or hstore-to-xml
or hstore-to-yaml. Just something that parsers are
readily available for.
Heck, I wouldn't mind if
On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with
On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type
Robert Haas wrote:
On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Well, actually, now that you mention it: how much of a json type would
be duplicative of the xml stuff? Would it be
On Fri, Dec 18, 2009 at 7:05 PM, Andrew Dunstan and...@dunslane.net wrote:
One problem is that there is not a single well-defined mapping between
these types. I would say generally that XML and YAML both have more
types of constructs than JSON. The obvious ways of translating an
arbitrary
I just realized that this was easy to do, and despite my complete lack of C
skillz was able to throw this together in a couple of hours. It might be handy
to some, though the possible downsides are:
* No json_to_hstore().
* Leads to requests for hstore_to_yaml(), hstore_to_xml(), etc.
* Andrew
On Wed, Dec 16, 2009 at 2:28 PM, David E. Wheeler da...@kineticode.com wrote:
I just realized that this was easy to do, and despite my complete lack of C
skillz was able to throw this together in a couple of hours. It might be
handy to some, though the possible downsides are:
* No
On Dec 16, 2009, at 2:45 PM, Robert Haas wrote:
I like it. The regression tests you've added seem to cover a lot of
cases that aren't really different without covering some that are
probably worth trying, like multiple key/value pairs. Also, the
comment in the function you've added looks
On Wed, Dec 16, 2009 at 5:58 PM, David E. Wheeler da...@kineticode.com wrote:
On Dec 16, 2009, at 2:45 PM, Robert Haas wrote:
I like it. The regression tests you've added seem to cover a lot of
cases that aren't really different without covering some that are
probably worth trying, like
57 matches
Mail list logo
