Context & design feedback on my four open PRs (#984–#987 + harlequin-postgres#56) #989

Hi Ted 👋

Last week I opened four PRs (#984, #985, #986, #987, plus tconbeer/harlequin-postgres#56) without proposing them here first — I only just read CONTRIBUTING properly and realized Discussions is where feature ideas should start. Sorry for the cold PRs! Rather than opening four retroactive threads, here's the missing context in one place.

Background: I use Harlequin daily as my main SQL IDE against Postgres. These features all came from my personal fork, where I built them to smooth out my own browsing/editing workflow. I split them into small, independent PRs in the hope some are useful upstream.

The features:

1. feat: open a table's data on double-click / submit in the Data Catalog #984 — open a table's data on double-click / submit in the Data Catalog. Double-clicking a relation runs select * from <rel> limit 100 instead of just inserting the name into the editor. As flagged in the PR: this changes a default behavior, and I'm happy to gate it behind a config option (or drop it if you like the current behavior).
2. feat: clickable ✕ close button on each Query Editor tab #985 — clickable ✕ close button on each Query Editor tab. Small UX addition, no behavior changes otherwise.
3. feat: foreign-key navigation in the Results Viewer #986 — foreign-key navigation in the Results Viewer. FK cells get a ↗ glyph; clicking follows the reference. Requires adapter support — harlequin-postgres#56 adds foreign_key_columns() to the cursor.
4. feat: edit a result cell in place #987 (draft, stacked on feat: foreign-key navigation in the Results Viewer #986) — edit a result cell in place. Double-click a cell → edit modal → runs an UPDATE keyed on the primary key. Requires editable_columns() from the same adapter PR. This is the most opinionated of the four (a results viewer that can write back), so I fully understand if you'd want it opt-in — or consider it out of scope for Harlequin.

How they relate: #986 and #987 share the adapter plumbing in harlequin-postgres#56; #984 and #985 are independent of everything else. #987 stays draft until #986 lands (or doesn't).

No urgency on any of this — I'm running my fork happily in the meantime. Very open to reworking UX, gating behavior, or closing any PR that doesn't fit your vision for Harlequin. Thanks for building it!