Thanks
In the context of stored procedures API for Catalogs, this approach
deviates from the traditional definition of stored procedures in RDBMS for
two key reasons:
- Compilation vs. Interpretation: Traditional stored procedures are
typically pre-compiled into machine code for faster exec
Mich, I don't think the invalidation will be necessary in our case as there
is no plan to preprocess or compile the procedures into executable objects.
They will be loaded and executed on demand via the Catalog API.
пт, 10 трав. 2024 р. о 10:37 Mich Talebzadeh
пише:
> Hi,
>
> If the underlying t
Hi,
If the underlying table changes (DDL), if I recall from RDBMSs like Oracle,
the stored procedure will be invalidated as it is a compiled object. How is
this going to be handled? Does it follow the same mechanism?
Thanks
Mich Talebzadeh,
Technologist | Architect | Data Engineer | Generative
Thanks Anton for the updated proposal -- it looks great! I appreciate the
hard work put into refining it. I am looking forward to the upcoming vote
and moving forward with this initiative.
Thanks,
Huaxin
On Thu, May 9, 2024 at 7:30 PM L. C. Hsieh wrote:
> Thanks Anton. Thank you, Wenchen, Dongj
Thanks for leading this project! Let's move forward.
On Fri, May 10, 2024 at 10:31 AM L. C. Hsieh wrote:
> Thanks Anton. Thank you, Wenchen, Dongjoon, Ryan, Serge, Allison and
> others if I miss those who are participating in the discussion.
>
> I suppose we have reached a consensus or close to
Thanks Anton. Thank you, Wenchen, Dongjoon, Ryan, Serge, Allison and
others if I miss those who are participating in the discussion.
I suppose we have reached a consensus or close to being in the design.
If you have some more comments, please let us know.
If not, I will go to start a vote soon a
Thanks to everyone who commented on the design doc. I updated the proposal
and it is ready for another look. I hope we can converge and move forward
with this effort!
- Anton
пт, 19 квіт. 2024 р. о 15:54 Anton Okolnychyi пише:
> Hi folks,
>
> I'd like to start a discussion on SPARK-44167 that a
Hi folks,
I'd like to start a discussion on SPARK-44167 that aims to enable catalogs
to expose custom routines as stored procedures. I believe this
functionality will enhance Spark’s ability to interact with external
connectors and allow users to perform more operations in plain SQL.
SPIP [1] con
