ion feature for it because opening
>>> a session in PostgreSQL is expensive. PostgreSQL uses one
>>> process per session. If we open and close a session for
>>> each Flight SQL call, we need to start one process for each
>>> Flight SQL call.
>>>
>>> I not
for C++.
[1]: https://github.com/apache/arrow/pull/34817
On Wed, Feb 15, 2023, at 01:10, Sutou Kouhei wrote:
> Hi James,
>
> Thanks for sharing your plan! I will wait for an update.
>
> --
> kou
>
> In
>
>
> "Re: DISCUSS: [FlightSQL] Catalog support&
Hi James,
Thanks for sharing your plan! I will wait for an update.
--
kou
In
"Re: DISCUSS: [FlightSQL] Catalog support" on Tue, 14 Feb 2023 04:53:07 +,
James Duong wrote:
> Hi Sutou,
>
> I saw your PostgreSQL project and thought it was quite interesting,
>
.ms/AAb9ysg>
From: Sutou Kouhei
Sent: Thursday, February 9, 2023, 22:25
To: dev@arrow.apache.org
Subject: Re: DISCUSS: [FlightSQL] Catalog support
Hi James
Is there any progress of this?
I'm developing a Flight SQL adapter for PostgreSQL:
https://github
rrow-flight-sql-postgresql/issues/13
Thanks,
--
kou
In
"Re: DISCUSS: [FlightSQL] Catalog support" on Mon, 12 Dec 2022 18:12:06 +,
James Duong wrote:
> Hi David,
>
> I've written up the URI parsing in C++ and started adding session management
>
ther developer) will send an update once those features are
>> ready for demo.
>>
>> From: David Li
>> Sent: December 12, 2022 10:07 AM
>> To: dev@arrow.apache.org
>> Subject: Re: DISCUSS: [FlightSQL] Catalog support
>>
&
to report if sessions are enabled on
> the server.
>
> I (or another developer) will send an update once those features are ready
> for demo.
>
> From: David Li
> Sent: December 12, 2022 10:07 AM
> To: dev@arrow.apache.org
> Subject: Re: D
ready for
demo.
From: David Li
Sent: December 12, 2022 10:07 AM
To: dev@arrow.apache.org
Subject: Re: DISCUSS: [FlightSQL] Catalog support
Following up here, James are you interested in putting up a draft PR for the
Flight SQL URI format and for session manage
Following up here, James are you interested in putting up a draft PR for the
Flight SQL URI format and for session management?
The Flight SQL URI format would then also cover Andrew's use case. And if
someone wants to draw up a PR to the JDBC driver to enable arbitrary
properties, I can review
> Andrew, do we need to look into adding more metadata to indicate
different query languages? (It's quite a shame that we named this Flight
SQL at this point...)
TDLR is I don't think trying to explicitly support languages other than SQL
in FlightSQL is a good idea. Among other reasons, the JDBC /
Hey James, thanks for putting this up.
Inline:
> The suggestion is to make this part of Flight as an
> optional feature, rather than Flight SQL due to its applicability outside
> of just database access.
Which uses do you see? I see statefulness as a general antipattern here, so I'm
wary of int
Sorry for the late reply -- thank you James and David for this discussion.
I agree that adding Catalog support would be a valuable addition to Flight
SQL, and it recently came up as we begin to implement Flight SQL in
InfluxDB IOx [1].
> - A standard URI scheme for Flight SQL that can be used by
Just to chime in on this, one thing I'm curious about is whether there
will be support for user-defined catalog/schema hierarchy depth?
This comment that James made does seem reasonable to me
> scheme://:/path-1/path-2/.../path-n
Trino/Presto does a similar thing (jdbc:trino://localhost:8080/tpch
Our current convention of sending connection properties as headers with
every request has the benefit of making statefulness optional, but has the
drawback of sending redundant, unused properties on requests after the
first, which increases the payload size unnecessarily.
I'd suggest we define ses
It sounds reasonable - then there are three points:
- A standard URI scheme for Flight SQL that can be used by multiple client APIs
(JDBC, ADBC, etc.)
- A standard scheme for session data (likely header/cookie-based)
- A mapping from URI parameters and fields to session data
On Tue, Nov 22, 20
Just following up on this and if there are any thoughts.
The purpose would be to standardize how we specify access to some named
logical grouping of data. This would make it easy to model catalog/schema
semantics in Flight SQL.
Having this be part of the connection URI makes it similar to specify
As for surfacing catalogs itself, perhaps we allow the URI take in a path
and treat that as a way of specifying a multi-level resource that which the
FlightClient is connecting to:
eg a connection URI of the form:
scheme://:/path-1/path-2/.../path-n
The FlightClient could send this path as either
Sounds good to me.
> Are you interested in writing up a (sketch of a) proposal?
Yep, can do - I'm OoO over the next couple of weeks so might be a bit
intermittent.
On Thu, 10 Nov 2022 at 15:28, David Li wrote:
> Hey James H.,
>
> That would make sense to me. So it sounds like we'd want
>
> - F
Hey James H.,
That would make sense to me. So it sounds like we'd want
- Formal specification of using cookies/headers to mark a 'session' (I guess
this will be a little inconsistent with transactions, though)
- Adding RPCs to query session values
- Adding RPCs to set session values
- Listing st
Similarly, we're also currently considering how best to implement some of
the SQL standard session variables in our Flight SQL server - things like
current transaction isolation level, access mode, time zone etc, which seem
to have similar properties to the (traditional) connection's current
catalo
I think having better support for this makes sense, but perhaps we can find a
way to make it not tied to the connection itself? For instance, in the same way
transactions were implemented (as a handle). Or rather, instead of adding
connection statefulness to Flight RPC, I'd rather try to work wi
21 matches
Mail list logo
