Removing limitation of stringified `keys`

[KazimirPodolski]

Summary

The values in the keys list are always stringified, this is a known limitation due to interactions with GraphQL.

How about returning keys as JSON? It would make consuming non-trivial keys (like aggregation returning arrays) trivial on any frontend compared to parsing postgres-formatted strings.

I see that getting right proper type for each aggregation + field variant is not easy, but JSON keys is a change of just a couple of lines.

[benjie]

Adding an option to do that would be feasible, but I don't think I'd change the default behavior to it - not a big fan of the JSON scalar, [String] is a lot easier to handle in general (you don't have to check it's the shape you're expecting because GraphQL guarantees it).

[kamikat]

I'm wondering if it's possible to infer orderBy argument from subqueries like:

query TaskMetrics {
  tasks {
    aggregates {  # => groupedAggregates(groupBy: [TASK_TYPE]) { keys }
      groupBy {
        taskType
      }
      average {
        elapsedTime
      }
    }
  }
}

[benjie]

No; a field must not use its selection set to have an externally measurable difference in behaviour. We only use it as an optimisation, not to change behaviour