Dne 6.4.2010 7:57, Joseph Adams napsal(a):
On Tue, Apr 6, 2010 at 1:00 AM, Petr Jelinek<pjmo...@pjmodos.net> wrote:
Not really sure about this myself, but keep in mind that NULL has special
meaning in SQL.
To me, the most logical approach is to do the obvious thing: make
JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
NULLs in it and converting the result set to JSON would yield a
structure with 'null's in it. 'null'::JSON would yield NULL. I'm not
sure what startling results would come of this approach, but I'm
guessing this would be most intuitive and useful.
+1
Just a note, but PostgreSQL has some UTF-8 validation code, you might want
to look at it maybe, at least once you start the actual integration into
core, so that you are not reinventing too many wheels. I can see how your
own code is good thing for general library which this can (and I am sure
will be) used as, but for the datatype itself, it might be better idea to
use what's already there, unless it's somehow incompatible of course.
Indeed. My plan is to first get a strong standalone JSON library
written and tested so it can be used as a general-purpose library. As
the JSON code is merged into PostgreSQL, it can be adapted. Part of
this adaptation would most likely be removing the UTF-8 validation
function I wrote and using PostgreSQL's Unicode support code instead.
There are probably other bits that could be PostgreSQLified as well.
I wonder if I should consider leveraging PostgreSQL's regex support or
if it would be a bad fit/waste of time/slower/not worth it.
Regex ? What for ? You certainly don't need it for parsing, you have
good parser IMHO and regex would probably be all of the above.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
