Feature request: First-class, AI-callable export from executed SQL to 1:1 Python (mssql-python)

### Feature Description

### Feature request: First-class, AI-callable export from executed SQL to 1:1 Python (mssql-python)

**Summary**

The VS Code MSSQL extension has become an exceptionally strong AI work surface: SQL is deterministic, strongly typed, and safe for iterative refinement via Copilot agent tools.

The missing piece is a **lossless, first-class bridge** from executed SQL to runnable Python using the official `mssql-python` library.

Today, AI is already acting as informal glue between these layers. This request is about making that bridge explicit, deterministic, inspectable, and supported.

---

**Proposed feature**

Expose a small set of **deterministic, AI-callable export tools** that operate on the executed query context and its results:

- `#mssql_export_query_as_python`
- `#mssql_export_query_as_polars`

These tools would generate a **1:1 Python function** that:

- Preserves the exact SQL text that was executed
- Reuses the active VS Code connection profile (no secrets exported)
- Preserves parameterization as function arguments
- Uses the official `mssql-python` library
- Optionally returns a Polars DataFrame
- Optionally exposes result inspection for queries the agent already ran

---

## Real world example provided below!

### Problem and Motivation

**Problem**

In real-world SQL environments, queries often encode nuanced business logic:

- window functions and ranking rules
- temporal boundaries (DATEADD, EOMONTH, AT TIME ZONE)
- DECIMAL precision and scale
- NULL semantics (CASE, COALESCE, NULLIF)
- collation and string comparison behavior

Copilot works extremely well inside SQL because the language is constrained and deterministic.

What breaks is not *access* to the SQL, but the **artifact boundary** when crossing into Python:
- SQL logic exists only ephemerally inside the agent loop
- connection and parameter context are implicit, not materialized
- results cannot be inspected, replayed, or versioned as Python objects
- validated logic is easy to accidentally diverge from later

This introduces friction and, worse, silent logic drift.

---

**Current workflow that already works extremely well**

Using Copilot agent-mode tools exposed by the MSSQL extension, it is already possible to investigate complex SQL Server environments very effectively.

Typical investigation loop using real, existing tools:

- `#mssql_connect`
- `#mssql_list_tables`
- `#mssql_list_views`
- `#mssql_list_functions`
- `#mssql_list_procedures`
- `#mssql_list_schemas`
- `#mssql_run_query`

---

**Exact real-world Copilot interaction (scrubbed)**

Below is an exact example of a real Copilot session. Identifiers, IPs, and internal names have been scrubbed, but the structure and behavior are unchanged.

**User prompt (verbatim):**

> and not a chance it is in some lookup table or something?
> real fast...using `#mssql_connect` look around at the functions/stored procs/views/tables and see if anything hints at it...
> maybe it is there...but not a friendly design?

---

**Copilot agent execution (tool calls):**

- Connecting using a saved MSSQL profile
- Listing tables
- Listing views
- Listing functions
- Listing schemas

Then running multiple targeted schema-exploration queries, including:
- searching for views with `sic` in the name
- inspecting view definitions
- searching stored procedures related to SIC
- scanning object definitions for joins involving principal, SIC, and industry terms

Finally:
- Disconnecting from the MSSQL connection

This entire interaction is deterministic and driven exclusively by the MSSQL extension’s tool surface.

---

**Copilot response (verbatim content, scrubbed):**

> ## Quick read
> - Yes: there **is** a lookup/mapping layer — it’s just not “friendly” because the principal stores **SICID in a column named SICCode**.
> - The canonical “real SIC code + description” lives in a SIC lookup table.
> - A reporting view explicitly joins **Principal.SICCode → SICode.SICID**, which confirms the intended design.
>
> ## What I found in the database
> ### Core lookup tables
> - A SIC lookup table containing:
> - `SICID` (internal identifier)
> - `SICCode` (the real 3/4-digit SIC code)
> - `SICDescription`
> - An industry-type mapping table converting `IndustryTypeID` to a readable sector label
>
> ### A “friendly” view that proves the design
> - A reporting view whose definition explicitly performs:
> `Principal.SICCode = SICode.SICID`
> - The view then selects the real SIC code, description, and industry type
> - Translation: the system expects principal “SICCode” to store an ID, not the actual code
>
> ## Stored procedures that expose the lookup
> - Procedures returning `(SICID, SICCode, SICDescription)`
> - Procedures exposing industry-type mappings
>
> ## Bottom line
> There *is* a lookup-based friendly representation, but it is accessed via:
> **Principal.SICCode (ID)** → lookup table → **real SICCode / description**

No business logic was hallucinated.
The agent reconstructed this purely by inspecting SQL objects and validating joins.

---

**Clarification: this is not about copying SQL text**

This workflow does not require manually copying SQL today. Copilot can already reference and reuse executed queries informally.

The gap is that none of this work becomes a **first-class, inspectable Python artifact**.

What is currently missing:

- A way to inspect the *results* of tool-executed queries as Python objects
- A way to emit a Python function that encapsulates *exactly* what the agent validated
- A way to replay investigative steps programmatically (tests, regression checks, pipelines)
- A way to capture schema-discovery queries as auditable, versionable artifacts

Today, validated logic lives only inside the Copilot execution loop. It is powerful, but ephemeral.

---

**Missing step**

Once SQL logic is fully understood and validated, there is no first-class way to promote that work into **durable, replayable Python code** with 1:1 fidelity using `mssql-python`.

This is the only non-deterministic step in an otherwise deterministic workflow.

---

**Why this belongs in the MSSQL extension (not Copilot alone)**

- This is deterministic export, not AI inference
- The extension already has:
- executed SQL
- parameter context
- connection profile metadata
- Formalizing this reduces semantic drift and improves reliability, auditability, and reproducibility

This turns the MSSQL extension into a **first-class exploration-to-production bridge**.

---

**Non-goals (important)**

- No natural-language pipeline synthesis
- No ORM or framework generation
- No autonomous execution
- No credential export

---

**Why this matters now**

- The MSSQL extension already exposes structured Copilot agent tools (`#mssql_*`)
- `mssql-python` is GA and positioned as the official Python driver
- Power users are already performing this workflow manually or semi-formally

This proposal makes an emergent, high-value workflow explicit, durable, and supported.

---

**Target users**

Advanced data engineers and data scientists who:
- explore complex logic in SQL
- leverage Copilot as an execution agent
- ship production pipelines in Python
- care deeply about semantic fidelity, reproducibility, and auditability
```

### Related Area

- [ ] Connection dialog (SQL Server | Azure browse/Fabric browse)
- [x] Query editor
- [x] Query results panel
- [x] Object Explorer
- [x] GitHub Copilot integration
- [x] Preview/Edit data
- [ ] Table Designer
- [ ] Schema Designer
- [ ] Schema Compare
- [ ] Local SQL Server Container provisioning
- [ ] SQL database in Fabric provisioning
- [ ] DACPAC/BACPAC export/import
- [ ] SQL Database projects
- [ ] Query Plan Visualizer
- [ ] Other (please describe below)

### If you selected "Other", please describe the area

_No response_

### Confirmation

- [x] I have searched existing feature requests and couldn't find a match
- [x] I want to help implement this feature