use 'lit' as the field name for literal values

[adriangb]

As per #16491 (comment) I think it's a bit strange that we try to create a field name from the repr of the value.

Consider this example: https://datafusion.apache.org/user-guide/sql/scalar_functions.html#id273
For cases of an array with hundreds of elements it will blow up and make a mess!

Could we use a fixed constant like 'lit' or 'field' instead?

The main issue I could see happening is name collisions, e.g. select 1, 2, 3 will cause an error which is unfortunate, not sure how to resolve that but also the current behavior isn't much better:

> select 1, 1;
Error during planning: Projections require unique expression names but the expression "Int64(1)" at position 0 and "Int64(1)" at position 1 have the same name. Consider aliasing ("AS") one of them.

FWIW Postgres seems to have the concept of an "un-named" column:

ff=# select 1, 2, 3;
 ?column? | ?column? | ?column? 
----------+----------+----------
        1 |        2 |        3

But I'm not sure we want to introduce an "unnamed" field.

[alamb]

This makes sense to me -- thank you @adriangb

[alamb]

FYI @timsaucer

[timsaucer]

This sounds reasonable, especially since the final schema will not use the field name here. If we change that at some point I could see it causing a problem.

[adriangb]

Thanks folks. One more thought: I wonder if this improves performance by some small fraction given that I could see lit(..) being called in hot loops in some place and this was innocently calling a pretty complex Display impl that e.g. iterated over list literals.

Anyway I pla to leave this open for review for another day or so then I'll merge it.

[alamb]

If we see string allocations on the hot path, perhaps we could do something like cache the FieldRef for each datatype or something 🤔

[alamb]

(As a follow on PR, to be clera)