Re: Supporting named row construction in Calcite SQL

Yes. “Ask Julian”. The picture is in a Google Slides document. I don’t want to share it publicly, and I don’t want to check in a massive .SVG file. I don’t think it’s worth the effort to make this small part of the process scalable. > On Apr 16, 2018, at 5:22 PM, Shuyi Chen

Re: Supporting named row construction in Calcite SQL

Thanks a lot, Julian. Do we have instructions on how to update the website and the picture documented? On Mon, Apr 16, 2018 at 4:42 AM, Michael Mior wrote: > Thanks Julian! > > -- > Michael Mior > mm...@apache.org > > -- > Michael Mior > mm...@uwaterloo.ca > > 2018-04-16

Re: Supporting named row construction in Calcite SQL

Thanks Julian! -- Michael Mior mm...@apache.org -- Michael Mior mm...@uwaterloo.ca 2018-04-16 2:26 GMT-04:00 Julian Hyde : > Beam and HerdDB are now on “powered by”: https://calcite.apache.org/ > docs/powered_by.html > > > On

Re: Supporting named row construction in Calcite SQL

Beam and HerdDB are now on “powered by”: https://calcite.apache.org/docs/powered_by.html > On Apr 12, 2018, at 5:33 AM, Michael Mior wrote: > > FYI, I talked to Julian earlier this week and he will be adding Beam to the >

Re: Supporting named row construction in Calcite SQL

FYI, I talked to Julian earlier this week and he will be adding Beam to the powered by page since he has a doc for generating the image with the logos. -- Michael Mior mm...@apache.org 2018-04-12 4:06 GMT-04:00 Shuyi Chen : > @Andrew, great to see BEAM is also using Calcite

Re: Supporting named row construction in Calcite SQL

For what it’s worth, ROW is standard SQL. If it does what you need, we should use it. Reading your case quickly, I perceived that you needed a concise way to assign field names, and AS STRUCT seemed to do that. But staying within the standard is always preferred. BigQuery isn’t always good at

Re: Supporting named row construction in Calcite SQL

Thanks for the fantastic proposal @shuyi. I think the STRUCT idea is great considering ROW is not standard SQL either. As a user of calcite I have a couple questions. Since ROW constructor is so similar with STRUCT, would it be a good idea to consolidate the two syntax? Or have a clear

Re: Supporting named row construction in Calcite SQL

As a user of Calcite working on adding streaming SQL to Apache Beam this sounds like a fantastic proposal. Our initial goal is to be able to run SQL queries that transform arbitrary JSON objects. Without this syntax objects must be flattened when they pass through the transform. Is this something

Re: Supporting named row construction in Calcite SQL

@Michael, @Albert, yes, I dont think it is SQL standard. But I think it's very useful in the context of streaming SQL, e.g. Flink SQL, where the sinks can be a database or endpoints with defined protobuf/thrift schema. They usually have complex structure. Supporting complex structure in SQL output

Re: Supporting named row construction in Calcite SQL

If I recall correctly, Google BigQuery has SELECT AS STRUCT. It’s not standard, but if it does what you need we could consider adopting that syntax. Julian > On Apr 4, 2018, at 10:23 AM, Albert wrote: > > if it is not SQL standard, it's just a matter of categorizing it

Re: Supporting named row construction in Calcite SQL

Apologies for my silence. I don't really have thoughts on the matter at this point. It might be helpful if you can give an example of what you're proposing. Unless I'm missing something (very possible), it's not part of the SQL standard. -- Michael Mior mm...@apache.org 2018-04-03 18:48

Re: Supporting named row construction in Calcite SQL

Friendly ping, any thoughts? Much appreciated. Shuyi On Tue, Mar 27, 2018 at 11:59 PM, Shuyi Chen wrote: > Hi community, > > I am thinking of adding the following support in Calcite to support named > row construction, e.g. > > SELECT (a as first_name, b as last_name, (c as

Supporting named row construction in Calcite SQL

Hi community, I am thinking of adding the following support in Calcite to support named row construction, e.g. SELECT (a as first_name, b as last_name, (c as zip code, d as street, e as state) as address) as record FROM example_table The output will be struct with field names specified in the