rfc: Range & Multirange types

[esseswann]

Is your proposal related to a problem?

Ranges & Multiranges are parsed inconveniently likewise other specific data type
Related to #1082

Describe the solution you'd like

Ranges should compile into GraphQL json-serializable input\output types with the following structure, using tstzrange as an example

type tstz_range_bound {
  inclusive: boolean!
  value: timestamptz ## Null indicates infinity
}

type tstz_range {
  upper: range_bound!
  lower: range_bound!
}

## multirange example
type table {
  tstz_multirange: [range!]!
}

input tstz_range_bound_input {
  inclusive: boolean!
  value: timestamptz ## Null indicates infinity
}

input tstz_range_input {
  upper: tstz_range_bound_input!
  lower: tstz_range_bound_input!
}

input tstz_range_comparison_bool_exp {
  _cnt_range: tstz_range_input! ## @>
  _ncnt_range: tstz_range_input! ## @>
  _cnt: timestamptz! ## @>
  _ncnt: timestamptz! ## @>
  ## ...so on
}

input tstz_multirange_comparison_bool_exp {
  _cnt_range: [tstz_range_input!]! ## @>
  _ncnt_range: [tstz_range_input!]! ## @>
  _cnt: timestamptz! ## @>
  _ncnt: timestamptz! ## @>
  ## ...so on
}

## and update timestamptz 
input timestamptz_comparison_exp {
  _in_range: [tstz_range_input!]! ## <@
  _nin_range: [tstz_range_input!]! ## <@
  ## ...so on
}

Such or similar fieldnames are recommended to use so there is no camelCase\snake_case controversy

Describe alternatives you've considered

Write views per table containing range\multirange columns that would return JSON or columns named like start_end

If the feature is approved, would you be willing to submit a PR?

Yes