Dne 6.4.2010 7:57, Joseph Adams napsal(a):
> On Tue, Apr 6, 2010 at 1:00 AM, Petr Jelinek<pjmodos@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)
