Re: remaining sql/json patches
Alvaro Herrera <alvherre@alvh.no-ip.org>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
SQL/JSON: Various improvements to SQL/JSON query function docs
- ce416fadb4b6 17.0 landed
- 42de72fa7b80 18.0 landed
-
SQL/JSON: Fix some obsolete comments.
- 290a6d800d90 17.0 landed
- 7768b6569de9 16.4 landed
- 3a8a1f3254b2 18.0 landed
-
SQL/JSON: Fix issues with DEFAULT .. ON ERROR / EMPTY
- c0fc0751862d 17.0 landed
-
JSON_TABLE: Add support for NESTED paths and columns
- bb766cde63b4 17.0 landed
-
Fix JsonExpr deparsing to emit QUOTES and WRAPPER correctly
- f6a2529920cf 17.0 landed
-
Fix typo introduced in 6185c9737
- 2f6e78b0619a 17.0 landed
-
Add basic JSON_TABLE() functionality
- de3600452b61 17.0 landed
-
Avoid splitting errmsg string to span multiple lines
- 085e759e9da7 17.0 landed
-
Add SQL/JSON query functions
- 6185c9737cf4 17.0 landed
-
Implement various jsonpath methods
- 66ea94e8e606 17.0 cited
-
Add soft error handling to some expression nodes
- aaaf9449ec6b 17.0 landed
- 7fbc75b26ed8 17.0 landed
-
Adjust populate_record_field() to handle errors softly
- 1edb3b491bee 17.0 landed
-
Refactor code used by jsonpath executor to fetch variables
- faa2b953ba3b 17.0 landed
-
Test EXPLAIN (FORMAT JSON) ... XMLTABLE
- 752533d40fd5 17.0 landed
-
Simplify productions for FORMAT JSON [ ENCODING name ]
- d3fe6e90bab5 17.0 landed
-
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited
-
doc: add missing <returnvalue> and whitespace
- e055b6be7ebb 17.0 landed
-
Add more SQL/JSON constructor functions
- 03734a7fed7d 17.0 landed
-
Rename a nonterminal used in SQL/JSON grammar
- 254ac5a7c31f 17.0 landed
-
Some refactoring to export json(b) conversion functions
- b22391a2ff7b 17.0 landed
-
Don't include CaseTestExpr in JsonValueExpr.formatted_expr
- 66a9003e2e3e 16.0 landed
- b6e1157e7d33 17.0 landed
-
Code review for commit b6e1157e7d
- 7c7412cae3ea 17.0 landed
-
Pass constructName to transformJsonValueExpr()
- 7825a1b01e40 16.0 landed
- 785480c9533d 17.0 landed
-
Unify JSON categorize type API and export for external use
- 3c152a27b063 17.0 landed
-
Make some indentation in gram.y consistent
- 5edf438eeb00 17.0 landed
- 01f1f789df56 16.0 landed
-
Allow most keywords to be used as column labels without requiring AS.
- 06a7c3154f5b 14.0 cited
-
Reduce size of backend scanner's tables.
- 7f380c59f800 13.0 cited
-
Use perfect hashing, instead of binary search, for keyword lookup.
- c64d0cd5ce24 12.0 cited
Attachments
- 0001-trivial-fixups.notpatch (text/plain)
I looked at your 0001. My 0001 are some trivial comment cleanups to that. I scrolled through all of jsonfuncs.c to see if there was a better place for the new function than the end of the file. Man, is that one ugly file. There are almost no comments! I almost wish you would create a new file so that you don't have to put this new function in such bad company. But maybe it'll improve someday, so ... whatever. In the original code, the functions here being (re)moved do not need to return a type output function in a few cases. This works okay when the functions are each contained in a single file (because each function knows that the respective datum_to_json/datum_to_jsonb user of the returned values won't need the function OID in those other cases); but as an exported function, that strange API doesn't seem great. (It only works for 0002 because the only thing that the executor does with these cached values is call datum_to_json/b). That seems easy to solve, since we can return the hardcoded output function OID in those cases anyway. A possible complaint about this is that the OID so returned would be untested code, so they might be wrong and we'd never know. However, ISTM it's better to make a promise about always returning a function OID and later fixing any bogus function OID if we ever discover that we return one, rather than having to document in the function's comment that "we only return function OIDs in such and such cases". So I made this change my 0002. A similar complain can be made about which casts we look for. Right now, only an explicit cast to JSON is useful, so that's the only thing we do. But maybe one day a cast to JSONB would become useful if there's no cast to JSON for some datatype (in the is_jsonb case only?); and maybe another type of cast would be useful. However, that seems like going too much into uncharted territory with no useful use case, so let's just not go there for now. Maybe in the future we can improve this aspect of it, if need arises. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/