Thanks. I’ve responded in the case.
> On Feb 19, 2023, at 1:17 AM, Istvan Toth <[email protected]> wrote:
>
> (Added the same comment to the ticket)
>
> Hi!
>
> Instead of adding new properties, IMO wo should transparently relay all
> non-avatica properties to the server, and let the proxied driver handle
> them. That would solve both this problem, and add the ability to set any
> driver specific properties from the Avatica client.
>
> (We could also introduce a special property where the relayed properties
> could be set instead)
>
> i.e
>
>
> *jdbc:avatica:remote:url=remoteserver;driverspecific1=a;driverspecifc2=b*
> or
>
>
> *jdbc:avatica:remote:url=remoteserver;relayoption=driverspecifc1ESCEQaESCCOMMAdrivespecific2ESCEQb*
> and these would be set for the proxied connection as
>
> as jdbc:proxied?driverspecific1=a&driverspecific2=b
>
> See https://issues.apache.org/jira/browse/CALCITE-4121
>
> On Sat, Feb 18, 2023 at 4:32 AM Julian Hyde <[email protected]> wrote:
>
>> TJ has logged a case [1] proposing to add a "userAgent" connection
>> property to Avatica. (It would be inherited by all drivers, e.g.
>> Calcite, that use Avatica.)
>>
>> The intent is that userAgent would indicate the client program. Do we
>> need additional properties for client process ID? I know these are
>> fairly common in JDBC and ODBC drivers.
>>
>> Julian
>>
>> [1] https://issues.apache.org/jira/browse/CALCITE-5534
>>
>
>
> --
> *István Tóth* | Sr. Staff Software Engineer
> *Email*: [email protected]
> cloudera.com <https://www.cloudera.com>
> [image: Cloudera] <https://www.cloudera.com/>
> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
> on LinkedIn] <https://www.linkedin.com/company/cloudera>
> ------------------------------
> ------------------------------
