Support array input parameters

[msullivan]

If I try to specify an array input param in the CLI, I get

Unimplemented input type descriptor: Array(ArrayTypeDescriptor { id: 4cf81264-f02d-46d6-ff1d-9f46c355fb3e, type_pos: TypePos(0), dimensions: [None] })

[jackfischer]

Would question this being minor. Arrays are common and we often copy/paste queries with param from QB into the CLI.

[msullivan]

@tailhook could you take a look at this soon? Tuples, also.

Last year I hacked up something that basically worked (228cec1) but felt like it might be too hacky even by my standards, which think are lower than @tailhook's

So it might require a more substantial rework of input parsing

[msullivan]

There is one potential actual UI design question, which is how to syntactically represent arrays of str, given that plain strs are just entered in without quotes or anything, but I think the only really reasonable answer is "quoted using edgeql's lexical conventions"

[tailhook]

I don't expect that I have time for this in 3.0 timeframe. This might be introduced in 3.x cycle.

There is one potential actual UI design question, which is how to syntactically represent arrays of str, given that plain strs are just entered in without quotes or anything, but I think the only really reasonable answer is "quoted using edgeql's lexical conventions"

For testing queries, I've expected something along the lines of:

> SELECT <array<str>>$arr
Variable $arr[0]: element1
Variable $arr[1]: element2
Variable $arr[2]: <Ctrl+D>

But if people use arrays in REPL a lot, it will not be very convenient. Also I wanted to be able to switch between input modes via a keyboard shortcut. But rustlyline we use, don't work well with custom shortcuts.

[msullivan]

One difficulty with the multi-entry approach is that if we have <optional array<str>>$0, we would struggle to distinguish between empty set and empty array.

[jackfischer]

Occurs to me on another reading that "minor" might have referred to implementation difficulty! Sorry for the presumptuous comment

[msullivan]

Occurs to me on another reading that "minor" might have referred to implementation difficulty! Sorry for the presumptuous comment

No, your interpretation was right as was (in my opinion at least) your disagreement with tagging it "minor".
The main reason it took so long to get fixed was that the implementation actually was pretty involved, since
the whole input parsing system needed to be redone in a way that supported composition of the parsers.