Dmitry Yemanov

Do we expect any more commits inside this PR? Or can it be merged now?

I reduced this test case to queries: ``` SELECT count(*) FROM ROZLICZENIE RL WHERE RL.OKRES_NUMER BETWEEN '15' AND '18' AND RL.ROZLICZ_RODZ_DZIAL_ID IN ('1', '5', '7', '9') AND RL.ROZLICZ_PROGRAM = 'T'...

I played more with this test case and yes, v5 is constantly slower, although with a smaller degree than you see (2.5s vs 2.9s). This happens even with the IN...

Since we'll have to support both positions (for backward compatibility), I doubt this feature gonna add something but confusion.

While schemas are defined in the SQL specification, items (3) and (4) from your list are non-standard, AFAIU. I would think twice before considering them for implementation.

If `LISTAGG` is added for standard compatibility, should legacy `LIST` also support ordering? If yes, should it follow the standard syntax (so that `LIST` and `LISTAGG` just become synonyms) or,...

The standard `LISTAGG` also has the separator string being mandatory while our `LIST` implementation has it optional, with a comma implied if omitted. And the standard `LISTAGG` defines the separator...

Sorting may be mandatory in `LISTAGG` (as per SQL standard), but it must be optional (or missing completely) in `LIST` due to backward compatibility.

Oracle supports `LISTAGG` in mostly standard way (without ``), but it has optional separator. So maybe we should preserve this syntax.

IMHO it's better to have a standard function with non-standard extensions than implement a second non-standard function with these extensions. We have standard EXTRACT with non-standard QUARTER / MILLISECOND /...