I agree with the best effort type of conversion, and only being able to
handle JSON array's that conform to an SQL array. With that said I would
love to collaborate with you on this, but there is one thing holding me
back. The current company I work for (an insurance company) says it is a
conflict of interest so I have to be careful. I can try to help out in
other ways if possible, and I will double check with our HR.
On Tue, Sep 24, 2013 at 8:12 AM, Chris Travers <ch...@2ndquadrant.com>wrote:
> **
>
>
> > On 24 September 2013 at 13:46 Andrew Dunstan <and...@dunslane.net> wrote:
>
> >
> >
> > Feel free to ask questions.
> >
> > The heart of the API is the event handlers defined in this stuct in
> > include/utils/jsonapi.h:
> >
> > typedef struct JsonSemAction
> > {
> > void *semstate;
> > json_struct_action object_start;
> > json_struct_action object_end;
> > json_struct_action array_start;
> > json_struct_action array_end;
> > json_ofield_action object_field_start;
> > json_ofield_action object_field_end;
> > json_aelem_action array_element_start;
> > json_aelem_action array_element_end;
> > json_scalar_action scalar;
> > } JsonSemAction;
> >
> >
> > Basically there is a handler for the start and end of each non-scalar
> > structural element in JSON, plus a handler for scalars.
> >
> > There are several problems that will be posed by processing nested
> > arrays and objects, including:
> >
> > * in effect you would need to construct a stack of state that could be
> > pushed and popped
>
> True.
>
> > * JSON arrays aren't a very good match for SQL arrays - they are
> > unidimensional and heterogenous.
>
> This is true, but I think one would have to start with an assumption that
> the data is valid for an SQL type and then check again once one gets it
> done. JSON is a pretty flexible format which makes it a poor match in
> many cases for SQL types generally. But I think the example so far (with
> json_populate_recordset) is a good one, namely a best effort conversion.
>
> >
> >
> > I'm not saying this can't be done - it will just take a bit of effort.
>
> Yeah, looking through the code, I think it will be more work than I
> originally thought but that just means it will take longer.
> >
> > cheers
> >
> > andrew
> >
> >
> >
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
> Best Wishes,
> Chris Travers
> http://www.2ndquadrant.com
> PostgreSQL Services, Training, and Support
>
