findepi closed pull request #13489: Support duplicate column aliases in queries
URL: https://github.com/apache/datafusion/pull/13489
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comm
github-actions[bot] commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2613718048
Thank you for your contribution. Unfortunately, this pull request is stale
because it has been open 60 days with no activity. Please remove the stale
label or comment or
alamb commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2499131431
> Bugs happen and these are caught by ValidateDependenciesChecker (example
failure [trinodb/trino#22806](https://github.com/trinodb/trino/issues/22806)).
That error message is 😍
alamb commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2499093201
> > PhysicalExpr columns use ordinal offsets and they don't seem to have
generated too many debugging headaches
>
> a gin has been invoked - #13559
🤣 😭
--
This is an a
findepi commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2498838693
> PhysicalExpr columns use ordinal offsets and they don't seem to have
generated too many debugging headaches
a gin has been invoked - https://github.com/apache/datafusion/issu
findepi commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2495552886
This is anecdote-based, so i will add mine. In Trino the planner uses
symbols (single per-query global namespace). Bugs happen and these are caught
by ValidateDependenciesChecker (ex
alamb commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2495462188
> > That being said, DataFusion PhysicalExpr columns use ordinal offsets and
they don't seem to have generated too many debugging headaches
>
> That may be because we prune colum
findepi commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2495455935
> That being said, DataFusion PhysicalExpr columns use ordinal offsets and
they don't seem to have generated too many debugging headaches
That may be because we prune columns o
alamb commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2495449641
> On the last DF contributor call @alamb mentioned many hours spent
debugging why column ordinals are incorrect when working on PostgreSQL
internals.
> Being cautious of engineers'
findepi commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2494043790
> We might need to introduce [column
index](https://github.com/apache/datafusion/blob/main/datafusion/physical-expr/src/expressions/column.rs#L71)
to differentiate them.
This
jonahgao commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2490576881
> The less easy part is that
>
> ```sql
> select * from (select 1 as a, 2 as a) t;
> ```
>
> should work. However, the `*` gets expanded to Expr expressions and th
findepi commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2488695180
> We can delay the name ambiguity check until a real column reference
occurs. But currently, it seems that this check is not sufficient. For example
>
> ```shell
> DataFusio
findepi commented on code in PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#discussion_r1849941066
##
datafusion/expr/src/logical_plan/ddl.rs:
##
@@ -285,8 +288,234 @@ impl PartialOrd for CreateExternalTable {
}
}
+impl CreateExternalTable {
+pub fn
jonahgao commented on code in PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#discussion_r1849701626
##
datafusion/expr/src/logical_plan/ddl.rs:
##
@@ -285,8 +288,234 @@ impl PartialOrd for CreateExternalTable {
}
}
+impl CreateExternalTable {
+pub fn
jonahgao commented on PR #13489:
URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2487708356
> allow creation of schemas for duplicated names
I think it's a good idea, as it allows the schema of the top plan to include
duplicate names, thereby resolving #6543.
15 matches
Mail list logo
