Re: jsonpath - Mailing list pgsql-hackers

Hi,

On 2019-01-30 07:34:00 +0300, Alexander Korotkov wrote:
> Thank you for your review!  Let me answer some points of your review
> while others will be answered later.
> 
> On Wed, Jan 30, 2019 at 5:28 AM Andres Freund <andres@anarazel.de> wrote:
> > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > > +/*****************************INPUT/OUTPUT*********************************/
> >
> > Why do we need this much code to serialize data that we initially got in
> > serialized manner? Couldn't we just keep the original around?
> 
> As I get, you concern related to fact that we have jsonpath in text
> form (serialized) and convert it to the binary form (also serialized).
> Yes, we should do so.  Otherwise, we would have to parse jsonpath for
> each evaluation.  Basically, for the same reason we have binary
> representation for jsonb.

But why can't we keep the text around, instead of having all of that
code for converting back?


> > > +++ b/src/backend/utils/adt/jsonpath_exec.c
> >
> > Gotta say, I'm unenthusiastic about yet another execution engine in some
> > PG subsystem.
> 
> Better ideas?  I can imagine we can evade introduction of jsonpath
> datatype and turn jsonpath into executor nodes.  But I hardly can
> imagine you would be more enthusiastic about that :)

Not executor nodes, I think it could be possible to put it into the
expression evaluation codepaths, but it's probably too different to fit
well (would get you JIT compilation of the whole thing tho).

> > > @@ -206,6 +206,22 @@ Section: Class 22 - Data Exception
> > >  2200N    E    ERRCODE_INVALID_XML_CONTENT                                    invalid_xml_content
> > >  2200S    E    ERRCODE_INVALID_XML_COMMENT                                    invalid_xml_comment
> > >  2200T    E    ERRCODE_INVALID_XML_PROCESSING_INSTRUCTION                     invalid_xml_processing_instruction
> > > +22030    E    ERRCODE_DUPLICATE_JSON_OBJECT_KEY_VALUE                        duplicate_json_object_key_value
> > > +22031    E    ERRCODE_INVALID_ARGUMENT_FOR_JSON_DATETIME_FUNCTION
invalid_argument_for_json_datetime_function
> > > +22032    E    ERRCODE_INVALID_JSON_TEXT                                      invalid_json_text
> > > +22033    E    ERRCODE_INVALID_JSON_SUBSCRIPT                                 invalid_json_subscript
> > > +22034    E    ERRCODE_MORE_THAN_ONE_JSON_ITEM                                more_than_one_json_item
> > > +22035    E    ERRCODE_NO_JSON_ITEM                                           no_json_item
> > > +22036    E    ERRCODE_NON_NUMERIC_JSON_ITEM                                  non_numeric_json_item
> > > +22037    E    ERRCODE_NON_UNIQUE_KEYS_IN_JSON_OBJECT                         non_unique_keys_in_json_object
> > > +22038    E    ERRCODE_SINGLETON_JSON_ITEM_REQUIRED                           singleton_json_item_required
> > > +22039    E    ERRCODE_JSON_ARRAY_NOT_FOUND                                   json_array_not_found
> > > +2203A    E    ERRCODE_JSON_MEMBER_NOT_FOUND                                  json_member_not_found
> > > +2203B    E    ERRCODE_JSON_NUMBER_NOT_FOUND                                  json_number_not_found
> > > +2203C    E    ERRCODE_JSON_OBJECT_NOT_FOUND                                  object_not_found
> > > +2203F    E    ERRCODE_JSON_SCALAR_REQUIRED                                   json_scalar_required
> > > +2203D    E    ERRCODE_TOO_MANY_JSON_ARRAY_ELEMENTS                           too_many_json_array_elements
> > > +2203E    E    ERRCODE_TOO_MANY_JSON_OBJECT_MEMBERS
> > >  too_many_json_object_members
> >
> > Are all of these invented by us?
> 
> None of them are invented by us.  All of them are part of SQL 2016 standard.

Cool.

Greetings,

Andres Freund