On 29/11/16 17:28, Nico Williams wrote: > On Tue, Nov 29, 2016 at 05:18:17PM +0100, Petr Jelinek wrote: >> Just to add to this, the SQL/JSON proposals I've seen so far, and what >> Oracle, MSSQL and Teradata chose to implement already is basically >> subset of jsonpath (some proposals/implementations also include >> lax/strict prefix keyword on top of that). I think that should give us >> some hint on what the base functionality should look like. > > Yes, that'd be base functionality. You can go above and beyond. >
But let's just do the base thing first before going to much more complicated endeavor, especially if this is supposed to be the first patch for Christian. Also, one of the points of the SQL is the compatibility so that's what we should strive for first, especially given that the syntax of the jq is not compatible AFAICS. > I agree with Pavel that jq could be used as a user-defined function, but > proper integration would be better because it would avoid the need to > format and parse JSON around calls to jq, and also because PG could > compile jq programs when preparing SQL statements. Besides, the libjq > jv API is *very* nice. > I think this would be good as extension first and then we can see what to do with it next (ie I agree with Pavel). -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
