get schema right after parse before interpertor execute

[youngsofun]

currently, to make sure we get the correct schema, we need to wait until the first block is generated and use the schema in the block.

some times we may want to get the schema earlier. e.g.

1. HTTP WebUI can show schema before showing data.
2. result_cache writer can be initialized in advance.

@leiysky

[leiysky]

It's possible to retrieve the result schema before actually lauching the query task, but I found we don't have a proper API to achieve this.

Do you have any idea on this?

[youngsofun]

put it more general: is in addition to the final result stream, handlers may need other infos, mainly 3 kinds

1. handler may need a schema to inited some Downstream processors.
2. handler may need to know the plan( and maybe some args too), some examples:
   1. current clickhouse handler handle insert special in a diff function
   2. presto like client-side-session implementation needs to know the current SQL is changing session settings/db , so it can told the client about the change
   3. worksheet may need to run multi SQL in one HTTP handler request (not sure if mysql/clickhouse need this too?)
      https://docs.snowflake.com/en/developer-guide/sql-api/submitting-multiple-statements.html
   4. clickhouse HTTP insert may need to stop parse after insert ... format xxx and treat the remaining as formatted data input strea currently we do not allow this pattern (onlyallow SQL in URL and data in body), but this make some client integration unable to work. ( it is better if the token is a stream instead of a vec),
3. status and statics of the execution

for now， all of these except multi SQL is not strong product demand.

about the API I can think of 2 styles:

1. expose the API of each step (parse, bind, ...)
2. an API like spark, return a ParseResult object and user call .get_output_schema(), get_logic_plan() , get_physical plan, run incrementally and store result of each step inside.
   • the obj in ctx to make it easy to access.

[leiysky]

I'm going to refactor the handler into a unified Session API in #5679.

1. handler may need a schema to inited some Downstream processors.

Would you mind providing a example of this? It seems not handler's job.

2. handler may need to know the plan( and maybe some args too), some examples
3. status and statics of the execution

Both of these can be involved in #5679

for now， all of these except multi SQL is not strong product demand.

AFAIK, the multiple-statements feature is usually used to utilize with auto commit, since the query result is not reasonible with multiple query statements.

[youngsofun]

handler may need a schema to inited some Downstream processors.
It seems not handler's job.

yes, the first version for result cache did not use the processor, to implement fast, it will be refactored later.

but this is a potential need: HTTP WebUI can show schema before showing data.

[leiysky]

We can show the result format in some place, I'll take care of this when designing the Session.