[RFC] Ops suggested modifications

[gmantele]

All these commits are modifications suggested by Ops IG during ADQL-2.1's RFC.

[msdemlei]

I'm fine wit the changes, but for match to make sense, the VARCHAR-s in its signature would need to be VARCHAR(*)-s.

(where I believe TEXT as a generic string type would be a good addition to our informal type collection -- but that's for another day).

[gmantele]

I'm fine wit the changes, but for match to make sense, the VARCHAR-s in its signature would need to be VARCHAR(*)-s.

(where I believe TEXT as a generic string type would be a good addition to our informal type collection -- but that's for another day).

Strictly speaking, this is true, although most of the DBMS accept VARCHAR with no parameter (in which case, it is equivalent to VARCHAR(*). That said, I actually wonder whether we should not rather make this parameter optional for CHAR, VARCHAR, BINARY and VARBINARY in ADQL-2.1. Honestly, it is very convenient to write just VARCHAR instead of VARCHAR(*).

TEXT is also convenient to write ; but that would be an addition to ADQL-2.1, which should not happen during RFC period unless we have strong reason for that. So, I agree let's do that in another ADQL version.

[msdemlei]

On Wed, Jul 26, 2023 at 03:18:30AM -0700, Grégory Mantelet wrote: rather make this parameter optional for `CHAR`, `VARCHAR`, `BINARY` and `VARBINARY` in ADQL-2.1. Honestly, it is very convenient to write just `VARCHAR` instead of `VARCHAR(*)`.

Interesting -- I wasn't aware of that (of course, I've been living in the paradise of postgres and sqlite with their TEXT type). Given that convention, from my side: feel free to merge.

[mbtaylor]

Thank you for addressing my comments. Looks good to me.

[mbtaylor]

Thanks, I think it improves readability (and may save paper).
All OK apart from one tiny bugfix required as noted.