Github user andyyangcn commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/833#discussion_r87959385
--- Diff: core/sql/common/json.h ---
@@ -0,0 +1,124 @@
+#ifndef JSON_H
+#define JSON_H
+
+#include "stringinfo.h"
+
+#ifndef NULL
+#define NULL ((void *) 0)
+#endif
+
+#ifndef true
+#define true ((bool) 1)
+#endif
+
+#ifndef false
+#define false ((bool) 0)
+#endif
+
+#define HIGHBIT (0x80)
+#define IS_HIGHBIT_SET(ch) ((unsigned char)(ch) & HIGHBIT)
+
+typedef enum
+{
+ JSON_TOKEN_INVALID,
+ JSON_TOKEN_STRING,
+ JSON_TOKEN_NUMBER,
+ JSON_TOKEN_OBJECT_START,
+ JSON_TOKEN_OBJECT_END,
+ JSON_TOKEN_ARRAY_START,
+ JSON_TOKEN_ARRAY_END,
+ JSON_TOKEN_COMMA,
+ JSON_TOKEN_COLON,
+ JSON_TOKEN_TRUE,
+ JSON_TOKEN_FALSE,
+ JSON_TOKEN_NULL,
+ JSON_TOKEN_END
+} JsonTokenType;
+
+typedef enum /* contexts of JSON
parser */
+{
+ JSON_OK = 0,
+ JSON_INVALID_TOKEN,
+ JSON_INVALID_VALUE, /* expecting a value */
+ JSON_INVALID_STRING, /* expecting a string (for a
field name) */
+ JSON_INVALID_ARRAY_START, /* saw '[', expecting value or
']' */
+ JSON_INVALID_ARRAY_NEXT, /* saw array element, expecting
',' or ']' */
+ JSON_INVALID_OBJECT_START, /* saw '{', expecting label or '}' */
+ JSON_INVALID_OBJECT_LABEL, /* saw object label, expecting ':' */
+ JSON_INVALID_OBJECT_NEXT, /* saw object value, expecting
',' or '}' */
+ JSON_INVALID_OBJECT_COMMA, /* saw object ',', expecting next label
*/
+ JSON_INVALID_END, /* saw the end of a
document, expect nothing */
+ JSON_END_PREMATURELY, /*the input ended prematurely*/
+ JSON_UNEXPECTED_ERROR
+} JsonReturnType;
+
+/*
+ * All the fields in this structure should be treated as read-only.
+ *
+ * If strval is not null, then it should contain the de-escaped value
+ * of the lexeme if it's a string. Otherwise most of these field names
+ * should be self-explanatory.
+ *
+ * line_number and line_start are principally for use by the parser's
+ * error reporting routines.
+ * token_terminator and prev_token_terminator point to the character
+ * AFTER the end of the token, i.e. where there would be a nul byte
+ * if we were using nul-terminated strings.
+ */
+typedef struct JsonLexContext
+{
+ char *input;
+ int input_length;
+ char *token_start;
+ char *token_terminator;
+ char *prev_token_terminator;
+ JsonTokenType token_type;
+ int lex_level;
+ int line_number;
+ char *line_start;
+ StringInfo strval;
+} JsonLexContext;
+
+typedef JsonReturnType (*json_struct_action) (void *state);
+typedef JsonReturnType (*json_ofield_action) (void *state, char *fname,
bool isnull);
+typedef JsonReturnType (*json_aelem_action) (void *state, bool isnull);
+typedef JsonReturnType (*json_scalar_action) (void *state, char *token,
JsonTokenType tokentype);
+
+/*
+ * Semantic Action structure for use in parsing json.
+ * Any of these actions can be NULL, in which case nothing is done at that
+ * point, Likewise, semstate can be NULL. Using an all-NULL structure
amounts
+ * to doing a pure parse with no side-effects, and is therefore exactly
+ * what the json input routines do.
+ *
+ * The 'fname' and 'token' strings passed to these actions are palloc'd.
--- End diff --
Postgresql uses palloc function to allocate memories from memory pool. So,
when I porting the code, I remove that part and use malloc as a replace. For
postgresql, developer doesn't need to care about when to release the memory,
because when the request is completed, all memory allocated in the request will
be release. I'm not sure if Trafodion has the same mechanism to manage memory,
if yes, I can use that to replace palloc.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
