On Tue, 2012-01-31 at 12:58 -0500, Andrew Dunstan wrote:
On 01/30/2012 10:37 AM, Andrew Dunstan wrote:
Aside: is query_to_json really necessary? It seems rather ugly and
easily avoidable using row_to_json.
I started with this, again by analogy with query_to_xml(). But I agree
On 04/16/2012 09:34 AM, Hannu Krosing wrote:
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
The only comment I have here is that query_to_json could have been
replaced with json_agg, so thet you don't need to do double-buffering
for
On Mon, Apr 16, 2012 at 9:10 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/16/2012 09:34 AM, Hannu Krosing wrote:
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
The only comment I have here is that query_to_json could have
On Mon, 2012-04-16 at 10:10 -0400, Andrew Dunstan wrote:
On 04/16/2012 09:34 AM, Hannu Krosing wrote:
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
The only comment I have here is that query_to_json could have been
replaced
On Mon, Apr 16, 2012 at 11:19 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
If doing something in 9.3 then what I would like is some way to express
multiple queries. Basically a variant of
query_to_json(query text[])
where queries would be evaluated in order and then all the results
At 2012-02-01 11:28:50 -0500, robertmh...@gmail.com wrote:
It's also pretty clear that JSON
string - PG text data type is going to admit of a number of error
conditions (transcoding errors and perhaps invalid surrogate pairs) so
throwing one more on the pile doesn't cost much.
Hi Robert.
On Thu, Feb 2, 2012 at 4:54 AM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2012-02-01 11:28:50 -0500, robertmh...@gmail.com wrote:
It's also pretty clear that JSON
string - PG text data type is going to admit of a number of error
conditions (transcoding errors and perhaps invalid surrogate
At 2012-02-02 08:54:32 -0500, robertmh...@gmail.com wrote:
Someone is eventually going to propose a function with a name like
json_to_string() which, when given this JSON object, returns a
three-character string with the PostgreSQL text type.
Ah, that's the bit I was missing. I thought you
On Tue, Jan 31, 2012 at 11:46 PM, Andrew Dunstan and...@dunslane.net wrote:
The array(select...) locution turns out to have less flexibility than the
array_agg(record-ref) locution.
Less flexible maybe, but it can cleaner for exactly the type of
queries that will tend to come up in exactly the
On Tue, Jan 31, 2012 at 3:47 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
I'm mostly in favor of allowing \u. Banning \u means users
can't use JSON strings to marshal binary blobs, e.g. by escaping
non-printable characters and only using U+..U+00FF. Instead, they
have to use
On Mon, Jan 30, 2012 at 9:37 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/30/2012 09:54 AM, Abhijit Menon-Sen wrote:
At 2012-01-27 09:47:05 +0530, a...@toroid.org wrote:
I've started reviewing this patch, but it'll take me a bit longer to go
through json.c properly.
OK, I finished
On Mon, Jan 23, 2012 at 3:20 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-01-22 at 11:43 -0500, Andrew Dunstan wrote:
Actually, given recent discussion I think that test should just be
removed from json.c. We don't actually have any test that the code
point is valid (e.g. that it
On 01/30/2012 10:37 AM, Andrew Dunstan wrote:
Aside: is query_to_json really necessary? It seems rather ugly and
easily avoidable using row_to_json.
I started with this, again by analogy with query_to_xml(). But I agree
it's a bit ugly. If we're not going to do it, then we definitely
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do that, what would getting complete query results back from a
query look like? It's important to make this as simple for developers
as possible.
--
Josh Berkus
At 2012-01-31 12:04:31 -0500, robertmh...@gmail.com wrote:
That fails to answer the question of what we ought to do if we get an
invalid sequence there.
I think it's best to categorically reject invalid surrogates as early as
possible, considering the number of bugs that are related to them
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkus j...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do that, what would getting complete query results back from a
query look like? It's important to
On 01/31/2012 01:32 PM, Merlin Moncure wrote:
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkusj...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do that, what would getting complete query results
On Tue, Jan 31, 2012 at 12:48 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2012 01:32 PM, Merlin Moncure wrote:
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkusj...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to
On 01/31/2012 02:49 PM, Merlin Moncure wrote:
The major hole in functionality I see for heavy json users is the
reverse; how do you get json back into the database? With xml, at
least you could (ab)use xpath for that...with json you have to rely on
add-on support and/or ad hoc string parsing
On Tue, Jan 31, 2012 at 1:29 PM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2012-01-31 12:04:31 -0500, robertmh...@gmail.com wrote:
That fails to answer the question of what we ought to do if we get an
invalid sequence there.
I think it's best to categorically reject invalid surrogates as
On 01/31/2012 01:48 PM, Andrew Dunstan wrote:
On 01/31/2012 01:32 PM, Merlin Moncure wrote:
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkusj...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do
At 2012-01-27 09:47:05 +0530, a...@toroid.org wrote:
I've started reviewing this patch, but it'll take me a bit longer to go
through json.c properly.
OK, I finished reading json.c. I don't have an answer to the detoasting
question in the XXX comment, but the code looks fine.
Aside: is
On 01/30/2012 09:54 AM, Abhijit Menon-Sen wrote:
At 2012-01-27 09:47:05 +0530, a...@toroid.org wrote:
I've started reviewing this patch, but it'll take me a bit longer to go
through json.c properly.
OK, I finished reading json.c. I don't have an answer to the detoasting
question in the XXX
At 2012-01-15 11:08:05 -0500, and...@dunslane.net wrote:
Here's an update that adds row_to_json, plus a bit more cleanup.
I've started reviewing this patch, but it'll take me a bit longer to go
through json.c properly. Here are a few preliminary notes:
1. The patch has a lot of whitespace
On sön, 2012-01-22 at 11:43 -0500, Andrew Dunstan wrote:
Actually, given recent discussion I think that test should just be
removed from json.c. We don't actually have any test that the code
point is valid (e.g. that it doesn't refer to an unallocated code
point). We don't do that elsewhere
On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan and...@dunslane.net wrote:
Here's an update that adds row_to_json, plus a bit more cleanup.
why not call all these functions 'to_json' and overload them?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 01/23/2012 05:21 PM, Merlin Moncure wrote:
On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstanand...@dunslane.net wrote:
Here's an update that adds row_to_json, plus a bit more cleanup.
why not call all these functions 'to_json' and overload them?
I don't honestly feel that advances
2012/1/23 Merlin Moncure mmonc...@gmail.com:
On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan and...@dunslane.net wrote:
Here's an update that adds row_to_json, plus a bit more cleanup.
why not call all these functions 'to_json' and overload them?
-1
older proposal is more consistent with
On 01/21/2012 11:40 PM, Jeff Janes wrote:
On Sun, Jan 15, 2012 at 8:08 AM, Andrew Dunstanand...@dunslane.net wrote:
On 01/14/2012 03:06 PM, Andrew Dunstan wrote:
OK, here's a patch that does both query_to_json and array_to_json, along
with docs and regression tests. It include Robert's
On 01/22/2012 04:28 AM, Andrew Dunstan wrote:
On 01/21/2012 11:40 PM, Jeff Janes wrote:
On Sun, Jan 15, 2012 at 8:08 AM, Andrew Dunstanand...@dunslane.net
wrote:
On 01/14/2012 03:06 PM, Andrew Dunstan wrote:
OK, here's a patch that does both query_to_json and array_to_json,
along
On Sun, Jan 15, 2012 at 8:08 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/14/2012 03:06 PM, Andrew Dunstan wrote:
OK, here's a patch that does both query_to_json and array_to_json, along
with docs and regression tests. It include Robert's original patch, although
I can produce a
On Fri, Jan 20, 2012 at 12:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/19/2012 04:12 PM, Robert Haas wrote:
On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstanand...@dunslane.net wrote:
The spec only allows unescaped Unicode chars (and for our
Robert Haas robertmh...@gmail.com writes:
The code I've written so far does no canonicalization of the input
value of any kind, just as we do for XML.
Fair enough.
So, given that framework, what the patch does is this: if you're using
UTF-8, then \u is accepted, provided that is
On Fri, Jan 20, 2012 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The code I've written so far does no canonicalization of the input
value of any kind, just as we do for XML.
Fair enough.
So, given that framework, what the patch does is this: if
On 01/20/2012 09:19 AM, Robert Haas wrote:
On Fri, Jan 20, 2012 at 12:07 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstanand...@dunslane.net writes:
On 01/19/2012 04:12 PM, Robert Haas wrote:
On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstanand...@dunslane.netwrote:
The spec only
On Fri, Jan 20, 2012 at 10:45 AM, Andrew Dunstan and...@dunslane.net wrote:
XML's #; escape mechanism is more or less the equivalent of JSON's
\u. But XML documents can be encoded in a variety of encodings,
including non-unicode encodings such as Latin-1. However, no matter what the
On Jan 19, 2012, at 9:07 PM, Tom Lane wrote:
If his client encoding is UTF8, the value will be letter-perfect JSON
when it gets to him; and if his client encoding is not UTF8, then he's
already pretty much decided that he doesn't give a fig about the
Unicode-centricity of the JSON spec, no?
On Jan 20, 2012, at 8:58 AM, Robert Haas wrote:
If, however,
we're not using UTF-8, we have to first turn \u into a Unicode
code point, then covert that to a character in the database encoding,
and then test for equality with the other character after that. I'm
not sure whether that's
On Fri, Jan 20, 2012 at 09:12:13AM -0800, David E. Wheeler wrote:
On Jan 19, 2012, at 9:07 PM, Tom Lane wrote:
If his client encoding is UTF8, the value will be letter-perfect JSON
when it gets to him; and if his client encoding is not UTF8, then he's
already pretty much decided that he
On 01/20/2012 11:58 AM, Robert Haas wrote:
On Fri, Jan 20, 2012 at 10:45 AM, Andrew Dunstanand...@dunslane.net wrote:
XML's#; escape mechanism is more or less the equivalent of JSON's
\u. But XML documents can be encoded in a variety of encodings,
including non-unicode encodings such
On Fri, Jan 20, 2012 at 12:14 PM, David E. Wheeler da...@kineticode.com wrote:
On Jan 20, 2012, at 8:58 AM, Robert Haas wrote:
If, however,
we're not using UTF-8, we have to first turn \u into a Unicode
code point, then covert that to a character in the database encoding,
and then test
Robert Haas robertmh...@gmail.com writes:
Err, actually, now that I think about it, that might be a problem:
what happens if we're trying to test two characters for equality and
the encoding conversion fails?
This is surely all entirely doable given the encoding infrastructure
we already have.
On Fri, Jan 20, 2012 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Err, actually, now that I think about it, that might be a problem:
what happens if we're trying to test two characters for equality and
the encoding conversion fails?
This is surely
On Sat, Jan 14, 2012 at 3:06 PM, Andrew Dunstan and...@dunslane.net wrote:
Second, what should be do when the database encoding isn't UTF8? I'm
inclined to emit a \u escape for any non-ASCII character (assuming it
has a unicode code point - are there any code points in the non-unicode
On 01/19/2012 03:49 PM, Robert Haas wrote:
In other words, let's decree that when the database encoding isn't
UTF-8, *escaping* of non-ASCII characters doesn't work. But
*unescaped* non-ASCII characters should still work just fine.
The spec only allows unescaped Unicode chars (and for our
On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/19/2012 03:49 PM, Robert Haas wrote:
In other words, let's decree that when the database encoding isn't
UTF-8, *escaping* of non-ASCII characters doesn't work. But
*unescaped* non-ASCII characters should still
On 01/19/2012 04:12 PM, Robert Haas wrote:
On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstanand...@dunslane.net wrote:
On 01/19/2012 03:49 PM, Robert Haas wrote:
In other words, let's decree that when the database encoding isn't
UTF-8, *escaping* of non-ASCII characters doesn't work. But
On Thu, Jan 19, 2012 at 5:59 PM, Andrew Dunstan and...@dunslane.net wrote:
OK, then we need to say that very clearly and up front (including in the
EXPLAIN docs.)
Can do.
Of course, for data going to the client, if the client encoding is UTF8,
they should get legal JSON, regardless of what
On Jan 19, 2012, at 4:27 PM, Robert Haas wrote:
I think the real fix for this problem is to introduce an
infrastructure inside the database that allows us to have different
columns stored in different encodings. People use bytea for that
right now, but that's pretty unfriendly: it would be
Andrew Dunstan and...@dunslane.net writes:
On 01/19/2012 04:12 PM, Robert Haas wrote:
On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstanand...@dunslane.net wrote:
The spec only allows unescaped Unicode chars (and for our purposes that
means UTF8). An unescaped non-ASCII character in, say,
On 01/14/2012 03:06 PM, Andrew Dunstan wrote:
OK, here's a patch that does both query_to_json and array_to_json,
along with docs and regression tests. It include Robert's original
patch, although I can produce a differential patch if required. It can
also be pulled from
2012/1/14 Andrew Dunstan and...@dunslane.net:
On 01/12/2012 10:51 AM, Andrew Dunstan wrote:
On 01/12/2012 10:44 AM, Pavel Stehule wrote:
2012/1/12 Andrew Dunstanand...@dunslane.net:
On 01/12/2012 09:00 AM, Joey Adams wrote:
I wrote an array_to_json function during GSoC 2010:
On Sat, Jan 14, 2012 at 3:06 PM, Andrew Dunstan and...@dunslane.net wrote:
Second, what should be do when the database encoding isn't UTF8? I'm
inclined to emit a \u escape for any non-ASCII character (assuming it
has a unicode code point - are there any code points in the non-unicode
On 01/14/2012 06:11 PM, Joey Adams wrote:
On Sat, Jan 14, 2012 at 3:06 PM, Andrew Dunstanand...@dunslane.net wrote:
Second, what should be do when the database encoding isn't UTF8? I'm
inclined to emit a \u escape for any non-ASCII character (assuming it
has a unicode code point - are
I am very interested in experimenting with functional indexes into JSON
structures. I think this could be very powerful combined with full text
search as well as constraints. It would allow for using postgres as an
unstructured data store without sacrificing the powerful indexing features,
I wrote an array_to_json function during GSoC 2010:
http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289
It's not exposed as a procedure called array_to_json: it's part of the
to_json function, which decides what to do based on the argument type.
- Joey
--
Sent
On 01/12/2012 09:00 AM, Joey Adams wrote:
I wrote an array_to_json function during GSoC 2010:
http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289
It's not exposed as a procedure called array_to_json: it's part of the
to_json function, which decides what to do
2012/1/12 Andrew Dunstan and...@dunslane.net:
On 01/12/2012 09:00 AM, Joey Adams wrote:
I wrote an array_to_json function during GSoC 2010:
http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289
It's not exposed as a procedure called array_to_json: it's part of the
On 01/12/2012 10:44 AM, Pavel Stehule wrote:
2012/1/12 Andrew Dunstanand...@dunslane.net:
On 01/12/2012 09:00 AM, Joey Adams wrote:
I wrote an array_to_json function during GSoC 2010:
http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289
It's not exposed as a
On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/12/2012 10:44 AM, Pavel Stehule wrote:
this should be little bit more enhanced to support a row arrays - it
can be merged with some routines from pst tool
2012/1/12 Merlin Moncure mmonc...@gmail.com:
On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/12/2012 10:44 AM, Pavel Stehule wrote:
this should be little bit more enhanced to support a row arrays - it
can be merged with some routines from pst tool
On 01/12/2012 11:21 AM, Merlin Moncure wrote:
On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstanand...@dunslane.net wrote:
On 01/12/2012 10:44 AM, Pavel Stehule wrote:
this should be little bit more enhanced to support a row arrays - it
can be merged with some routines from pst tool
On 01/11/2012 01:18 AM, Pavel Stehule wrote:
I like this patch and this feature.
I'm about to read the patch in detail - I certainly like the feature.
I see only one issue - there is not functionality that helps generate
JSON in pg.
What do you think about functions:
2012/1/11 Andrew Dunstan and...@dunslane.net:
On 01/11/2012 01:18 AM, Pavel Stehule wrote:
I like this patch and this feature.
I'm about to read the patch in detail - I certainly like the feature.
I see only one issue - there is not functionality that helps generate
JSON in pg.
On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2012/1/11 Robert Haas robertmh...@gmail.com:
On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
Are people explicitly asking for a)
2012/1/11 Robert Haas robertmh...@gmail.com:
On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2012/1/11 Robert Haas robertmh...@gmail.com:
On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 20, 2011, at 10:39 AM, Claes
On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I don't understand why we have to do it?
We don't support similar functionality for XML, so why for JSON?
Hrm. Well, that's an interesting point. Maybe we don't. I assumed
that people would eventually want to
2012/1/11 Robert Haas robertmh...@gmail.com:
On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I don't understand why we have to do it?
We don't support similar functionality for XML, so why for JSON?
Hrm. Well, that's an interesting point. Maybe we don't. I
On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I understand it now. My opinion is so some operators and index search
can be in 9.2 - so use a JSON just as communication format now.
* we need to build JSON
* we need to check if some is valid JSON
* we need to
2012/1/11 Robert Haas robertmh...@gmail.com:
On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I understand it now. My opinion is so some operators and index search
can be in 9.2 - so use a JSON just as communication format now.
* we need to build JSON
* we need
Sent: 11/01/2012 16:22
To: Robert Haas
Cc: David E. Wheeler; Claes Jakobsson; Dimitri Fontaine; Merlin
Moncure; Andrew Dunstan; Magnus Hagander; Jan Urbański; Simon Riggs;
Joey Adams; Bruce Momjian; PostgreSQL-development Hackers; Jan Wieck
Subject: Re: [HACKERS] JSON for PG 9.2
2012/1/11 Robert
On 01/11/2012 10:21 AM, Pavel Stehule wrote:
2012/1/11 Robert Haasrobertmh...@gmail.com:
On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
I understand it now. My opinion is so some operators and index search
can be in 9.2 - so use a JSON just as communication
On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler da...@kineticode.com wrote:
On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
Are people explicitly asking for a) *JSON* datatype or b) a type that lets
you store arbitrary complex semi-untyped data structures?
Yes.
if b) then this might
2012/1/11 Robert Haas robertmh...@gmail.com:
On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
Are people explicitly asking for a) *JSON* datatype or b) a type that lets
you store arbitrary complex semi-untyped
Let me mention another lightweight data-interchange format.
At http://www.janestreet.com we have developed a small c module to deal
with S-expressions (sexp) as a way to store arbitrary data. As we write
most of our code in OCaml sexps are a natural way for us to store data.
David E. Wheeler da...@justatheory.com writes:
holds: it is not a programming language, and one does not need a PL to have
a JSON data type.
Exactly. That does not contradict the fact that if you have
pl/ecmascript you already have JSON. And that we might as well have had
the ecmascript PL
On Tuesday, December 20, 2011 07:23:43 PM Dimitri Fontaine wrote:
David E. Wheeler da...@justatheory.com writes:
holds: it is not a programming language, and one does not need a PL to
have a JSON data type.
Exactly. That does not contradict the fact that if you have
pl/ecmascript you
On Dec 20, 2011, at 12:39 AM, David E. Wheeler wrote:
On Dec 19, 2011, at 2:49 AM, Dimitri Fontaine wrote:
My understanding is that JSON is a subset of ECMAscript
Well, no, JSON is formally “a lightweight data-interchange format.” It’s
derived from JavaScript syntax, but it is not a
On Mon, Dec 19, 2011 at 5:49 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
My understanding is that JSON is a subset of ECMAscript, so if you get
the latter you already have the former. Now, someone would have to
check if plscheme still build with guile-2.0, and given that, how
exactly
On Dec 19, 2011, at 9:00 PM, Robert Haas wrote:
+1, though I think the core type will at least need some basic operators and
indexing support.
And I'm willing to do that, but I thought it best to submit a bare
bones patch first, in the hopes of minimizing the number of
objectionable
On Dec 20, 2011, at 2:13 AM, Magnus Hagander wrote:
Yes, that's why I said few not none.
Though in my experience, most companies are a lot more restrictive
about addons to their database than addons to their development
environments.
Yeah, we’re getting off-topic here, so I’ll just say
On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
Are people explicitly asking for a) *JSON* datatype or b) a type that lets
you store arbitrary complex semi-untyped data structures?
Yes.
if b) then this might get a lot more interesting
JSON is the most popular/likely way to represent
On Tue, Dec 20, 2011 at 00:26, David E. Wheeler da...@kineticode.com wrote:
On Dec 18, 2011, at 4:41 AM, Magnus Hagander wrote:
We can hopefully get around this for the extensions in contrib (and
reasonably well has already), but few large companies are going to be
happy to go to pgxn and
On Tue, Dec 20, 2011 at 06:00, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 19, 2011 at 6:26 PM, David E. Wheeler da...@kineticode.com
wrote:
+1, though I think the core type will at least need some basic operators and
indexing support.
And I'm willing to do that, but I thought it
Merlin Moncure mmonc...@gmail.com writes:
Getting back on point, I'm curious about your statement: without
writing a single line of C. I took a look at the pl/scheme docs and
was pretty impressed -- what exactly would be involved to get a
guile-based ECMAscript working over the pl/scheme
On Dec 18, 2011, at 4:41 AM, Magnus Hagander wrote:
We can hopefully get around this for the extensions in contrib (and
reasonably well has already), but few large companies are going to be
happy to go to pgxn and download an extension that has a single
maintainer (not the team, and in most
On Dec 19, 2011, at 3:39 PM, David E. Wheeler wrote:
Well, no, JSON is formally “a lightweight data-interchange format.” It’s
derived from JavaScript syntax, but it is not a programming language, so I
wouldn’t say it was accurate to describe it as a subset of JS or ECMAScript.
Bah, it says
On Dec 19, 2011, at 2:49 AM, Dimitri Fontaine wrote:
My understanding is that JSON is a subset of ECMAscript
Well, no, JSON is formally “a lightweight data-interchange format.” It’s
derived from JavaScript syntax, but it is not a programming language, so I
wouldn’t say it was accurate to
On Mon, Dec 19, 2011 at 6:26 PM, David E. Wheeler da...@kineticode.com wrote:
+1, though I think the core type will at least need some basic operators and
indexing support.
And I'm willing to do that, but I thought it best to submit a bare
bones patch first, in the hopes of minimizing the
On 18/12/11 04:21, Robert Haas wrote:
On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler da...@kineticode.com
wrote:
Love having the start here. I forwarded this message to Claes Jakobsson,
creator of the jansson-using pg-json extension. He’s a bit less supportive.
He gave me permission to
2011/12/18 Jan Urbański wulc...@wulczer.org:
On 18/12/11 04:21, Robert Haas wrote:
On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler da...@kineticode.com
wrote:
Love having the start here. I forwarded this message to Claes Jakobsson,
creator of the jansson-using pg-json extension. He’s a
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 17, 2011 at 5:02 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I'd like to add some confusion on the implementation choice, because it
looks damn too easy now… Guile 2.0 offers an implementation of the
ECMAscript language and plscheme
On Sun, Dec 18, 2011 at 10:49, Jan Urbański wulc...@wulczer.org wrote:
On 18/12/11 04:21, Robert Haas wrote:
On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler da...@kineticode.com
wrote:
Love having the start here. I forwarded this message to Claes Jakobsson,
creator of the jansson-using
On Sat, Dec 17, 2011 at 4:02 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote: to add some confusion on the
implementation choice, because it
looks damn too easy now… Guile 2.0 offers an implementation of the
ECMAscript language and plscheme already exists as a PostgreSQL PL extension
for
On 12/18/2011 12:17 PM, Merlin Moncure wrote:
One small note about the json type being an extension -- this probably
means the json type oid won't be fixed -- not a huge deal but it could
affect some corner cases with binary format consumers.
Why would that matter more for JSON than for
On Sun, Dec 18, 2011 at 11:21 AM, Andrew Dunstan and...@dunslane.net wrote:
On 12/18/2011 12:17 PM, Merlin Moncure wrote:
One small note about the json type being an extension -- this probably
means the json type oid won't be fixed -- not a huge deal but it could
affect some corner cases
Merlin Moncure mmonc...@gmail.com writes:
Why would that matter more for JSON than for any other non-core type?
well, it's a minor headache for all the oid-isn't-in-pgtypes.h types,
and only then for high traffic types (which presumably json will be).
Extensions are going to be more and more
On Sun, Dec 18, 2011 at 12:26 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Merlin Moncure mmonc...@gmail.com writes:
Why would that matter more for JSON than for any other non-core type?
well, it's a minor headache for all the oid-isn't-in-pgtypes.h types,
and only then for high traffic
On Sat, Dec 17, 2011 at 2:26 AM, Robert Haas robertmh...@gmail.com wrote:
In the spirit of Simon's suggestion that we JFDI, I cooked up a patch
today that JFDI. See attached.
Which looks very good.
Comments
* Comment for IDENTIFICATION of json.c says contrib/json/json.c
* json.c contains a
Hi,
Peter Eisentraut pete...@gmx.net writes:
The way forward here is to maintain this as an extension, provide debs
and rpms, and show that that is maintainable. I can see numerous
advantages in maintaining a PL outside the core; especially if you are
still starting up and want to iterate
1 - 100 of 155 matches
Mail list logo
