Re: [HACKERS] JSON for PG 9.2

On Mon, Apr 16, 2012 at 11:19 AM, Hannu Krosing 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 > aggregated into on js

Re: [HACKERS] JSON for PG 9.2

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 > >

Re: [HACKERS] JSON for PG 9.2

On Mon, Apr 16, 2012 at 9:10 AM, 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

Re: [HACKERS] JSON for PG 9.2

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 t

Re: [HACKERS] JSON for PG 9.2

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()

Re: [HACKERS] JSON for PG 9.2

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 y

Re: [HACKERS] JSON for PG 9.2

On Thu, Feb 2, 2012 at 4:54 AM, Abhijit Menon-Sen 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 pairs) so

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

On Tue, Jan 31, 2012 at 3:47 PM, Joey Adams 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 base64 or similar. I a

Re: [HACKERS] JSON for PG 9.2

On Tue, Jan 31, 2012 at 11:46 PM, Andrew Dunstan 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 type of functional

Re: [HACKERS] JSON for PG 9.2

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 Berkus 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 g

Re: [HACKERS] JSON for PG 9.2

On Tue, Jan 31, 2012 at 1:29 PM, Abhijit Menon-Sen 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 early as

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

On Tue, Jan 31, 2012 at 12: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 Berkus  wrote: >>> >>> Andrew, >>> based on Abhijit's feeling and some discussion offline, the consensus seems to be to remove query_to_json.

Re: [HACKERS] JSON for PG 9.2

On 01/31/2012 01:32 PM, Merlin Moncure wrote: On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkus 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 l

Re: [HACKERS] JSON for PG 9.2

On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkus 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 make this

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

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 PostgreS

Re: [HACKERS] JSON for PG 9.2

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 nee

Re: [HACKERS] JSON for PG 9.2

On Mon, Jan 23, 2012 at 3:20 PM, Peter Eisentraut 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 doesn't re

Re: [HACKERS] JSON for PG 9.2

On Mon, Jan 30, 2012 at 9:37 AM, Andrew Dunstan 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 rea

Re: [HACKERS] JSON for PG 9.2

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 co

Re: [HACKERS] JSON for PG 9.2

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 query

Re: [HACKERS] JSON for PG 9.2

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 err

Re: [HACKERS] JSON for PG 9.2

2012/1/23 Merlin Moncure : > On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan 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 xml functions Pavel > > merlin -

Re: [HACKERS] JSON for PG 9.2

On 01/23/2012 05:21 PM, Merlin Moncure wrote: On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan 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 clarity much. And we mi

Re: [HACKERS] JSON for PG 9.2

On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan 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 changes to your subscrip

Re: [HACKERS] JSON for PG 9.2

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 elsewher

Re: [HACKERS] JSON for PG 9.2

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 Dunstan 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 regressi

Re: [HACKERS] JSON for PG 9.2

On 01/21/2012 11:40 PM, Jeff Janes wrote: On Sun, Jan 15, 2012 at 8:08 AM, Andrew Dunstan 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, alth

Re: [HACKERS] JSON for PG 9.2

On Sun, Jan 15, 2012 at 8:08 AM, Andrew Dunstan 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 diff

Re: [HACKERS] JSON for PG 9.2

On Fri, Jan 20, 2012 at 2:21 PM, Tom Lane wrote: > Robert Haas 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 e

Re: [HACKERS] JSON for PG 9.2

Robert Haas 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. We might need som

Re: [HACKERS] JSON for PG 9.2

On Fri, Jan 20, 2012 at 12:14 PM, David E. Wheeler 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 for equality

Re: [HACKERS] JSON for PG 9.2

On 01/20/2012 11:58 AM, Robert Haas wrote: On Fri, Jan 20, 2012 at 10:45 AM, Andrew Dunstan 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. Howeve

Re: [HACKERS] JSON for PG 9.2

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 th

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

On Fri, Jan 20, 2012 at 10:45 AM, Andrew Dunstan 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 > document encoding

Re: [HACKERS] JSON for PG 9.2

On 01/20/2012 09:19 AM, Robert Haas wrote: On Fri, Jan 20, 2012 at 12:07 AM, Tom Lane wrote: Andrew Dunstan writes: On 01/19/2012 04:12 PM, Robert Haas wrote: On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstanwrote: The spec only allows unescaped Unicode chars (and for our purposes that

Re: [HACKERS] JSON for PG 9.2

On Fri, Jan 20, 2012 at 10:27 AM, Tom Lane wrote: > Robert Haas 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

Re: [HACKERS] JSON for PG 9.2

Robert Haas 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 something that > equa

Re: [HACKERS] JSON for PG 9.2

On Fri, Jan 20, 2012 at 12:07 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 01/19/2012 04:12 PM, Robert Haas wrote: >>> On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan  wrote: The spec only allows unescaped Unicode chars (and for our purposes that means UTF8). An unescaped non-ASCI

Re: [HACKERS] JSON for PG 9.2

Andrew Dunstan writes: > On 01/19/2012 04:12 PM, Robert Haas wrote: >> On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan wrote: >>> The spec only allows unescaped Unicode chars (and for our purposes that >>> means UTF8). An unescaped non-ASCII character in, say, ISO-8859-1 will >>> result in someth

Re: [HACKERS] JSON for PG 9.2

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 b

Re: [HACKERS] JSON for PG 9.2

On Thu, Jan 19, 2012 at 5:59 PM, Andrew Dunstan 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 the database enco

Re: [HACKERS] JSON for PG 9.2

On 01/19/2012 04:12 PM, Robert Haas wrote: On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan 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 c

Re: [HACKERS] JSON for PG 9.2

On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan 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 work just fine.

Re: [HACKERS] JSON for PG 9.2

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 p

Re: [HACKERS] JSON for PG 9.2

On Sat, Jan 14, 2012 at 3:06 PM, Andrew Dunstan 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 > encodings that don't

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

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, durabi

Re: [HACKERS] JSON for PG 9.2

On 01/14/2012 06:11 PM, Joey Adams wrote: On Sat, Jan 14, 2012 at 3:06 PM, Andrew Dunstan 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

Re: [HACKERS] JSON for PG 9.2

On Sat, Jan 14, 2012 at 3:06 PM, Andrew Dunstan 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 > encodings that don't

Re: [HACKERS] JSON for PG 9.2

2012/1/14 Andrew Dunstan : > > > On 01/12/2012 10:51 AM, Andrew Dunstan wrote: >> >> >> >> On 01/12/2012 10:44 AM, Pavel Stehule wrote: >>> >>> 2012/1/12 Andrew Dunstan: On 01/12/2012 09:00 AM, Joey Adams wrote: > > I wrote an array_to_json function during GSoC 2010: > >>

Re: [HACKERS] JSON for PG 9.2

On 01/12/2012 11:21 AM, Merlin Moncure wrote: On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan 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 http://okbob.blogspot.com/2010

Re: [HACKERS] JSON for PG 9.2

2012/1/12 Merlin Moncure : > On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan 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 >>> http://okbob.blogspot.com/2010/11/new-

Re: [HACKERS] JSON for PG 9.2

On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan 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 >> http://okbob.blogspot.com/2010/11/new-version-of-pst-collection-is.html

Re: [HACKERS] JSON for PG 9.2

On 01/12/2012 10:44 AM, Pavel Stehule wrote: 2012/1/12 Andrew Dunstan: 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_t

Re: [HACKERS] JSON for PG 9.2

2012/1/12 Andrew Dunstan : > > > 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 >>

Re: [HACKERS] JSON for PG 9.2

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 b

Re: [HACKERS] JSON for PG 9.2

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 vi

Re: [HACKERS] JSON for PG 9.2

On 01/11/2012 10:21 AM, Pavel Stehule wrote: 2012/1/11 Robert Haas: On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule 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 t

Re: [HACKERS] JSON for PG 9.2

rom: Pavel Stehule 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

Re: [HACKERS] JSON for PG 9.2

2012/1/11 Robert Haas : > On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule > 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 >

Re: [HACKERS] JSON for PG 9.2

On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule 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 store JSON > > other

Re: [HACKERS] JSON for PG 9.2

2012/1/11 Robert Haas : > On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule > 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 eventua

Re: [HACKERS] JSON for PG 9.2

On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule 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 optimize queries of the f

Re: [HACKERS] JSON for PG 9.2

2012/1/11 Robert Haas : > On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule > wrote: >> 2012/1/11 Robert Haas : >>> On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler >>> wrote: On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote: > Are people explicitly asking for a) *JSON* datatype or b)

Re: [HACKERS] JSON for PG 9.2

On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule wrote: > 2012/1/11 Robert Haas : >> On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler >> 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

Re: [HACKERS] JSON for PG 9.2

2012/1/11 Andrew Dunstan : > > > 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. >> >>

Re: [HACKERS] JSON for PG 9.2

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: array_to_json(anyarr

Re: [HACKERS] JSON for PG 9.2

2012/1/11 Robert Haas : > On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler > 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. >>

Re: [HACKERS] JSON for PG 9.2

On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler 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 get a lot

Re: [HACKERS] JSON for PG 9.2

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. http://hg.ocaml.info/

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

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 > objectionabl

Re: [HACKERS] JSON for PG 9.2

On Mon, Dec 19, 2011 at 5:49 AM, Dimitri Fontaine 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 you get pl/ecmascrip

Re: [HACKERS] JSON for PG 9.2

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

Re: [HACKERS] JSON for PG 9.2

On Tuesday, December 20, 2011 07:23:43 PM Dimitri Fontaine wrote: > "David E. Wheeler" 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.

Re: [HACKERS] JSON for PG 9.2

"David E. Wheeler" 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 for some time now, w

Re: [HACKERS] JSON for PG 9.2

On Tue, Dec 20, 2011 at 06:00, Robert Haas wrote: > On Mon, Dec 19, 2011 at 6:26 PM, David E. Wheeler > 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 patc

Re: [HACKERS] JSON for PG 9.2

On Tue, Dec 20, 2011 at 00:26, David E. Wheeler 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 download an exte

Re: [HACKERS] JSON for PG 9.2

On Mon, Dec 19, 2011 at 6:26 PM, David E. Wheeler 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

Re: [HACKERS] JSON for PG 9.2

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 desc

Re: [HACKERS] JSON for PG 9.2

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 say

Re: [HACKERS] JSON for PG 9.2

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 m

Re: [HACKERS] JSON for PG 9.2

Merlin Moncure 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 implementation?

Re: [HACKERS] JSON for PG 9.2

On Sun, Dec 18, 2011 at 12:26 PM, Dimitri Fontaine wrote: > Merlin Moncure 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 w

Re: [HACKERS] JSON for PG 9.2

Merlin Moncure 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 used and “perv

Re: [HACKERS] JSON for PG 9.2

On Sun, Dec 18, 2011 at 11:21 AM, Andrew Dunstan 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 with binary

Re: [HACKERS] JSON for PG 9.2

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 an

Re: [HACKERS] JSON for PG 9.2

On Sat, Dec 17, 2011 at 4:02 PM, Dimitri Fontaine 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 integrating with Gu

Re: [HACKERS] JSON for PG 9.2

On Sun, Dec 18, 2011 at 10:49, Jan Urbański wrote: > On 18/12/11 04:21, Robert Haas wrote: >> On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler >> 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 l

Re: [HACKERS] JSON for PG 9.2

Robert Haas writes: > On Sat, Dec 17, 2011 at 5:02 PM, Dimitri Fontaine > 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 already exists as a PostgreSQL PL >

Re: [HACKERS] JSON for PG 9.2

2011/12/18 Jan Urbański : > On 18/12/11 04:21, Robert Haas wrote: >> On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler >> 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 ga

Re: [HACKERS] JSON for PG 9.2

On 18/12/11 04:21, Robert Haas wrote: > On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler > 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 quote him her

Re: [HACKERS] JSON for PG 9.2

On Sat, Dec 17, 2011 at 10:42 PM, David E. Wheeler wrote: > On Dec 17, 2011, at 7:40 PM, Tom Lane wrote: >> Well, I think that that's exactly the question here: if we do something >> in core, will it foreclose options for people who want to do add-ons? > > Why would it? They would just have to use

Re: [HACKERS] JSON for PG 9.2

On Dec 17, 2011, at 7:40 PM, Tom Lane wrote: > Well, I think that that's exactly the question here: if we do something > in core, will it foreclose options for people who want to do add-ons? Why would it? They would just have to use a different name. Best, David -- Sent via pgsql-hackers mai

  1   2   >