Note: If you like this idea check out: liteJQ: jq extension for SQLite

The pgJQ extension embeds the standard jq compiler and brings the much loved jq lang to Postgres.

It adds a jqprog data type to express jq programs and a jq(jsonb, jqprog) function to execute them on jsonb objects. It works seamlessly with standard jsonb functions, operators, and jsonpath.

SELECT jq('[{"bar": "baz", "balance": 7.77, "active":false}]'::jsonb, '.[0].bar');

  jq   
-------
 "baz"
(1 row)

You can run basic filters:

SELECT jq('[{"bar": "baz", "balance": 7.77, "active":false}]'::jsonb, '.[0].bar');

  jq   
-------
 "baz"
(1 row)

If you're a syntactic sugar addict, you can use the @@ operator to achieve the same. It's better be explicit with the ::jqprog when using operators.

SELECT '[{"bar": "baz", "balance": 7.77, "active":false}]' @@ '.[0].bar'::jqprog;

  jq   
-------
 "baz"
(1 row)

You can run more complex jq programs too:

SELECT jq('[true,false,[5,true,[true,[false]],false]]',
          '(..|select(type=="boolean")) |= if . then 1 else 0 end');

             jq              
-----------------------------
 [1, 0, [5, 1, [1, [0]], 0]]
(1 row)

SELECT jq('[1,5,3,0,7]' , '(.[] | select(. >= 2)) |= empty');

   jq   
--------
 [1, 0]
(1 row)

If you want to pass dynamic arguments to jqprog, you can pass them as a jsonb object and refer to them as $var.

select jq('{
  "runner": 1,
  "message": "jobStatus",
  "jobs": [
    {
      "id": 9,
      "is_successfull": true
    },
    {
      "id": 100,
      "is_successfull": false,
      "metdata": {
        "environ": "prod"
      }
    }
  ]
}'::jsonb, '.jobs[] | select(.is_successfull == $is_success and .id == 100) | .', '{"is_success": false, "id": 100}');

                                  jq                                  
----------------------------------------------------------------------
 {"id": 100, "metdata": {"environ": "prod"}, "is_successfull": false}
(1 row)

You can even chain jq and jsonpath together!

Note here that the later part - '{trans}' @> '{"cust": "baz"}' is jsonpath, not jq code.

SELECT jq('[
  {
    "cust": "baz",
    "trans": {
      "balance": 100,
      "date": "2023-08-01"
    },
    "active": true,
    "geo": {
      "branch": "paloukia"
    }
  }
]', '(.[] | select(.active == true))') - '{trans}' @> '{"cust": "baz"}';

 ?column? 
----------
 t
(1 row)

If you opt for using operators here, you should help the parser by adding parentheses and explicit casts.

SELECT ('[
  {
    "cust": "baz",
    "trans": {
      "balance": 100,
      "date": "2023-08-01"
    },
    "active": true,
    "geo": {
      "branch": "paloukia"
    }
  }
]' @@ '(.[] | select(.active == true))'::jqprog) - '{trans}' @> '{"cust": "baz"}';

It is strongly recommended to be explicit with type casts and ordering when using overloaded operators, especially when you're working a lot with text. Otherwise, you'll find yourself in an obfuscated labyrinth of jqprogs, jsonbs, jsonpaths and possibly tsvectors , impossible to escape from.

If you have superuser privileges in Postgres you can use the pg_read_file to run your queries on JSON files.

SELECT jq(pg_read_file('/path/to/f.json', '.[]'))

You can see more examples in the test cases or try reproducing the jq manual .

git clone https://github.com/Florents-Tselai/pgJQ.git
cd pgJQ
make install # set PG_CONFIG=/path/to/bin/pg_config if necessary.
make installcheck

In a Postgres session run

CREATE EXTENSION pgjq

pgJQ does not re-implement the jq lang in Postgres. It instead embeds the standard jq compiler and uses it to parse jq programs supplied in SQL queries. These programs are fed with jsonb objects as input.

jq has evolved from just a cli tool to a full-fledged DSL, but it still remains a 20-80 tool.

pgJQ has been TDDed against those 20% of the cases. If you come across regressions between vanilla jq and pgJQ, especially around piped filters or complex functions, please do add an issue, along with a test case!

Keeping in mind, though, that there's probably not much point reproducing the whole DSL in an RDBMS context.

Some known issues are:

• Only string, bool and numeric arguments can be passed to jqprog.
• Currently, jq programs including pipes, like .[] | .name are buggy and unpredictable.
• Modules are not supported, but they could be theoretically supported, given that Postgres is fairly open to dynamic loading.