Hi Amogh, Thanks for the feedback.
This makes sense and I am happy to adopt the postgres-style approach: consolidate into the existing influxdb provider and use runtime detection to dispatch between influxdb_client (2.x) and influxdb3-python (3.x). The main difference vs postgres is that the connection model itself changes(org+bucket for 2.x vs database for 3.x) and the query language changes entirely (Flux vs SQL), so some code separation is unavoidable. But keeping it all under one provider with runtime detection is the right call. I am working on updating the PR to reflect this. Thanks, Arpit Sent with Proton Mail secure email. On Wednesday, 18 March 2026 at 10:38 AM, Amogh Desai <[email protected]> wrote: > Hello Arpit, > > Thanks for initiating this. > > I checked the PR briefly and the first qn that pops to my head is what Elad > also commented on the PR about using the existing provider itself (I > understand > the incompatibility that you have mentioned fwiw) > > For maintainability purposes, I still wonder if there is a way to use the > existing > provider itself. Like I think postgres provider is a decent example for > this. It supports > both psycopg2 AND psycopg3 via runtime detection: > https://github.com/apache/airflow/blob/f386dd99ceed54e86ff3f84ef91d4bb320b148a8/providers/postgres/src/airflow/providers/postgres/hooks/postgres.py#L40 > > This is not blocking but something worth evaluating before creating a new > provider > in my opinion. > > > Thanks & Regards, > Amogh Desai > > > On Tue, Mar 17, 2026 at 6:26 PM Arpit Rathore <[email protected]> > wrote: > > > Hi Airflow community, > > > > I have been working on a new provider to support InfluxDB 3.x > > (Core/Enterprise/Cloud Dedicated): > > https://github.com/apache/airflow/pull/58929 > > > > InfluxDB 3.x uses a completely different Python client (influxdb3-python), > > SQL queries (vs Flux > > in 2.x), and a different connection model (database instead of > > org+bucket). There is no shared > > code with the existing influxdb provider - these are distinct integrations > > targeting different > > products. > > > > Per AIP-95, I am looking for: > > > > 1. A second steward - someone willing to co-maintain the provider through > > incubation > > 2. A committer sponsor - a committer willing to guide the provider through > > the incubation process > > > > I am committed to being the primary steward. The implementation is > > complete (hooks, operators, > > tests, docs). The main remaining work is rebasing and aligning with the > > latest CI/tooling setup. > > > > Would anyone be willing to step into either role? Happy to discuss further > > here or on Slack. > > > > Thanks,Arpit > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
