[HACKERS] Wishlist: parameterizable types

2011-12-21 Thread Joey Adams
This may be ambitious, but it'd be neat if PostgreSQL supported parameterizable types. For example, suppose a contrib module defines a pair type. It could be used as follows: CREATE TABLE my_table ( coord pair(float, float) ); The pair module could define functions like these

Re: [HACKERS] JSON for PG 9.2

2012-01-12 Thread Joey Adams
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

Re: [HACKERS] JSON for PG 9.2

2012-01-14 Thread Joey Adams
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

Re: [HACKERS] JSON for PG 9.2

2012-01-31 Thread Joey Adams
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

[HACKERS] libpq should have functions for escaping data for use in COPY FROM

2012-03-09 Thread Joey Adams
libpq has functions for escaping values in SQL commands (PQescapeStringConn, PQescapeByteaConn, and the new PQescapeLiteral), and it supports parameterizing queries with PQexecParams. But it does not (to my knowledge) have functions for escaping values for COPY FROM. COPY FROM is useful for

Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

2012-05-01 Thread Joey Adams
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing ha...@2ndquadrant.com wrote: Hi hackers After playing around with array_to_json() and row_to_json() functions a bit it I have a question - why do we even have 2 variants *_to_json() Here's the discussion where that decision was made:

Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

2012-05-01 Thread Joey Adams
On Tue, May 1, 2012 at 12:22 PM, Andrew Dunstan and...@dunslane.net wrote: Second, RFC 4627 is absolutely clear: a valid JSON value can only be an object or an array, so this thing about converting arbitrary datum values to JSON is a fantasy. If anything, we should adjust the JSON input

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-15 Thread Joey Adams
On Mon, Jul 4, 2011 at 10:22 PM, Joseph Adams joeyadams3.14...@gmail.com wrote: I'll try to submit a revised patch within the next couple days. Sorry this is later than I said. I addressed the issues covered in the review. I also fixed a bug where \u0022 would become , which is invalid JSON,

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-18 Thread Joey Adams
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, could the \u problem be finessed by leaving such escapes in source form? Yes, it could. However, it doesn't solve the problem of comparison (needed for member lookup), which requires canonicalizing the strings to be

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-19 Thread Joey Adams
On Mon, Jul 18, 2011 at 7:36 PM, Florian Pflug f...@phlo.org wrote: On Jul19, 2011, at 00:17 , Joey Adams wrote: I suppose a simple solution would be to convert all escapes and outright ban escapes of characters not in the database encoding. +1. Making JSON work like TEXT when it comes

Fwd: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-19 Thread Joey Adams
Forwarding because the mailing list rejected the original message. -- Forwarded message -- From: Joey Adams joeyadams3.14...@gmail.com Date: Tue, Jul 19, 2011 at 11:23 PM Subject: Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON To: Alvaro Herrera

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-19 Thread Joey Adams
On Wed, Jul 20, 2011 at 12:32 AM, Robert Haas robertmh...@gmail.com wrote: Thanks for the input.  I'm leaning in this direction too.  However, it will be a tad tricky to implement the conversions efficiently, ... I'm a bit confused, because I thought what I was talking about was not doing any

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-20 Thread Joey Adams
On Wed, Jul 20, 2011 at 6:49 AM, Florian Pflug f...@phlo.org wrote: Hm, I agree that we need to handle \u escapes in JSON input. We won't ever produce them during output though, right? We could, to prevent transcoding errors if the client encoding is different than the server encoding (and

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-22 Thread Joey Adams
I think I've decided to only allow escapes of non-ASCII characters when the database encoding is UTF8. For example, $$\u2013$$::json will fail if the database encoding is WIN1252, even though WIN1252 can encode U+2013 (EN DASH). This may be somewhat draconian, given that: * SQL_ASCII can

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-22 Thread Joey Adams
On Fri, Jul 22, 2011 at 7:12 PM, Robert Haas robertmh...@gmail.com wrote: Hmm.  That's tricky.  I lean mildly toward throwing an error as being more consistent with the general PG philosophy. I agree. Besides, throwing an error on duplicate keys seems like the most logical thing to do. The

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-23 Thread Joey Adams
Also, should I forbid the escape \u (in all database encodings)? Pros: * If \u is forbidden, and the server encoding is UTF-8, then every JSON-wrapped string will be convertible to TEXT. * It will be consistent with the way PostgreSQL already handles text, and with the decision to use

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-24 Thread Joey Adams
soon. On Sun, Jul 24, 2011 at 2:19 PM, Florian Pflug f...@phlo.org wrote: On Jul24, 2011, at 05:14 , Robert Haas wrote: On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams joeyadams3.14...@gmail.com wrote: ... Fortunately, JSON's definition of a number is its decimal syntax, so the algorithm

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-24 Thread Joey Adams
On Sun, Jul 24, 2011 at 2:19 PM, Florian Pflug f...@phlo.org wrote: The downside being that we'd then either need to canonicalize in the equality operator, or live with either no equality operator or a rather strange one. It just occurred to me that, even if we sort object members, texteq

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

2011-07-24 Thread Joey Adams
On Mon, Jul 25, 2011 at 1:05 AM, Joey Adams joeyadams3.14...@gmail.com wrote: Should we mimic IEEE floats and preserve -0 versus +0 while treating them as equal?  Or should we treat JSON floats like numeric and convert -0 to 0 on input?  Or should we do something else?  I think converting -0

Re: [HACKERS] JSON for PG 9.2

2011-12-13 Thread Joey Adams
On Mon, Dec 5, 2011 at 3:12 PM, Bruce Momjian br...@momjian.us wrote: Where are we with adding JSON for Postgres 9.2?  We got bogged down in the data representation last time we discussed this. We should probably have a wiki page titled JSON datatype status to help break the cycle we're in: *

Re: [HACKERS] JSON for PG 9.2

2011-12-16 Thread Joey Adams
On Fri, Dec 16, 2011 at 8:52 AM, Robert Haas robertmh...@gmail.com wrote: But I think the important point is that this is an obscure corner case. Let me say that one more time: obscure corner case! +1 The only reason JSON needs to care about this at all is that it allows \u1234 to mean