Can greptime support the same name column before statement_to_plan?

[yihong0618]

What type of enhancement is this?

User experience

What does the enhancement do?

for now seems greptime do not support same name column for the select stmt
very simple query will raise error

select 1,1;
--  Failed to plan SQL: 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.

and it seems from this line

greptimedb/src/query/src/planner.rs

Line 106 in f069ea0

.statement_to_plan(df_stmt)

datafusion side raise this error;

but for pg user(maybe others) it is a very common use case like

select oid, * from xxxx;

my question is that can we support that? I did some search like risingwave and databend seems support it. but I tried it kind of hard for me for support it myself, so I left this issue here.

and this feature also block some IDE like DBeaver support

@sunng87

Implementation challenges

No response

[yihong0618]

update:
datafusion do not support this yet..
https://github.com/apache/datafusion/blob/17446ada1261bebf10f33646c98e29c22140d7be/datafusion/sql/tests/sql_integration.rs#L564

[sunng87]

Yes, I remember there is a statement sent from dbeaver has this issue. It seems datafusion designed this with purpose. I can go upstream to ask about the rational

[yihong0618]

Yes, I remember there is a statement sent from dbeaver has this issue. It seems datafusion designed this with purpose. I can go upstream to ask about the rational

upstream working on this like: apache/datafusion#13489

and I searched GitHub Found the cube solution kind of tricky...

https://github.com/cube-js/cube/blob/8d714d6637862b36024aee5c3857267c0c167dbf/rust/cubesql/cubesql/src/compile/parser.rs#L64-L67

[sunng87]

Great. I think we can do the same as cube does. We do have a pre-processing module in servers::postgres called fixture for early return of some unsupported statements.