Why does Postgraphile's <X>Connection type allow NULLs in its nodes list?

Question

If I have table X , why does the Postgraphile-generated schema for XConnection allow nulls in the returned list?

type XConnection { nodes: [X]! }

instead of

type XConnection { nodes: [X!]! }

I could not come up with examples where either the allXs query or any 1-N relation to X would have a meaningful use of null in the list. This translates into an Option or Maybe type in a typed language which makes navigation cumbersome, so I'm wondering when it would be null .

And why does allXs return an XConnection (allowing a null list) instead of XConnection! ? Would a null here mean the same as empty [] ?

Thanks!

Answer 1

The reason is that create function x() returns setof my_table ... functions can return nulls as well as table rows. In my opinion, doing so is a bad practice. If you agree, and can commit to not doing so, then you can use the "no SETOF functions contain nulls" flag to add the missing not null you asked about.

-N, --no-setof-functions-contain-nulls
if none of your RETURNS SETOF compound_type functions mix NULLs with the results 
then you may enable this to reduce the nullables in the GraphQL schema

(I'm the PostGraphile maintainer, and added this option.)

As for the root level field allXs ; it's good practice in a GraphQL schema for all root level fields to be nullable because if they are not and one root level field fails (eg SQL query failed, or DB is not available right now) then the entire GraphQL result will be null, rather than just the field that failed. GraphQL is big on limiting failures to small areas, hence the "nullable by default" approach.