+1
On Sat, May 11, 2024 at 4:35 PM L. C. Hsieh wrote:
> +1
>
> On Sat, May 11, 2024 at 3:11 PM Chao Sun wrote:
> >
> > +1
> >
> > On Sat, May 11, 2024 at 2:10 PM L. C. Hsieh wrote:
> >>
> >> Hi all,
> >>
> >> I’d like to start a vote for SPIP: Stored Procedures API for Catalogs.
> >>
> >>
+1
On Sat, May 11, 2024 at 3:11 PM Chao Sun wrote:
>
> +1
>
> On Sat, May 11, 2024 at 2:10 PM L. C. Hsieh wrote:
>>
>> Hi all,
>>
>> I’d like to start a vote for SPIP: Stored Procedures API for Catalogs.
>>
>> Please also refer to:
>>
>>- Discussion thread:
>>
+1
On Sat, May 11, 2024 at 2:10 PM L. C. Hsieh wrote:
> Hi all,
>
> I’d like to start a vote for SPIP: Stored Procedures API for Catalogs.
>
> Please also refer to:
>
>- Discussion thread:
> https://lists.apache.org/thread/7r04pz544c9qs3gc8q2nyj3fpzfnv8oo
>- JIRA ticket:
Hi all,
I’d like to start a vote for SPIP: Stored Procedures API for Catalogs.
Please also refer to:
- Discussion thread:
https://lists.apache.org/thread/7r04pz544c9qs3gc8q2nyj3fpzfnv8oo
- JIRA ticket: https://issues.apache.org/jira/browse/SPARK-44167
- SPIP doc:
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
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
-1 (non-binding)
A small question, the tag is orphan but I suppose it should belong to the
master branch.
Seems YARN integration is broken due to javax => jakarta namespace migration,
I filled SPARK-48238, and left some comments on
https://github.com/apache/spark/pull/45154
Caused by:
