Proposal: write support for the JDBC data source

[ErikBPF]

Problem

The JDBC data source is read-only (connectorX). There is no way to df.write from Sail.

Proposal

Add a DataSourceArrowWriter to the same source. PostgreSQL uses Arrow-native ADBC adbc_ingest; MySQL and SQL Server use a SQLAlchemy fallback (no ADBC ingest driver exists for them). Supports append and overwrite (staging-swap).

Open questions for maintainers

1. Dependencies — the write path adds adbc-driver-postgresql, psycopg, sqlalchemy, pandas to the pysail[jdbc] extra; the MySQL/SQL Server DBAPI drivers (pymysql / pymssql) are installed by the user. Acceptable?
2. Overwrite semantics — PostgreSQL offers atomic (staging DROP+RENAME) and truncate; other dialects use a DELETE + INSERT … SELECT swap. Reasonable?
3. Dialect scope — PostgreSQL / MySQL / SQL Server to start, more via SQLAlchemy later. OK?

[linhr]

Thanks for this proposal. This is indeed an important feature to support.

And we appreciate your interest in contributing to Sail. Our review bandwidth is limited and currently we're somewhat overwhelmed by AI-generated code, so we'd appreciate it a lot if the PR shows evidence on thoughtful design and thorough testing efforts.

And since the CI for first-time contributors needs to be triggered manually, we recommend you start with one piece first to get familiar with the review expectation and codebase convention so that later PRs are more streamlined.

And you're welcomed to join our Slack community and we'd love to learn about how you use Sail and how we can better collaborate on the features you need. Sometimes a bug report or usage scenario is more helpful than the code, as the maintainer may move quicker in code generation once the feature scope and architecture design is clear.

This comment applies to the other issues #2165 and #2166.

[ErikBPF]

Sure thing!

Thanks for reading my proposal and sorry if I did something not in accordance to this repo best practices. I will review the pipeline and try to run tests on a fork of mine before committing from now on.

Once i find some time I will bring here evidences into PR bodies and do necessary fixes. Should I also address copilot feedbacks? They are usually a little sloppy, but if it is tuned for this repo I can implement them.

As for the two other PRs, I will start the exploration, but we can look at them after I am more aligned with your ways.

[ErikBPF]

Following up — the fixes and evidence are in now, and I validated the pipeline on my own fork before updating this PR (as promised).

• Ran on a fork first: the full suite is green — 69 tests (23 unit + 42 PostgreSQL integration + 4 live-container MySQL 8.4 / SQL Server 2022). Lint passes in CI; the earlier failures (hatch-ruff lint, prettier on the docs page, and psycopg missing from the hatch test env) are fixed at their source.
• Copilot: I went ahead and applied the two substantive items — post-commit staging cleanup no longer fails an already-committed overwrite, and the unsupported-dialect error no longer echoes the raw JDBC URL (avoids leaking embedded credentials). I skipped the stylistic suggestions.
• Keeping this as the single lead PR; the two catalog PRs stay drafts until the design on Proposal: CREATE OR REPLACE TABLE for the Iceberg REST catalog #2165 / Proposal: REPLACE TABLE for the Hive Metastore catalog #2166 is settled.

The full behavior breakdown (reads, PostgreSQL append/overwrite atomic+truncate, schema-qualified writes, concurrent-atomic safety, MySQL/SQL Server) is in the PR body.