[bug] Switch database on query/notebook gets stuck — cannot revert, queries fail on wrong database

[jcalfee]

Describe the bug
After using “Switch database...” from the query results toolbar (... menu), the notebook/query becomes permanently bound to the new database. It is not possible to switch back. All subsequent queries (including on different tables) fail with “relation does not exist” errors because they execute against the wrong database. The stuck state sometimes survives closing/reopening the .pgsql file and restarting VSCodium.

To Reproduce

1. Open a .pgsql notebook connected to Database A.
2. Run a successful query on a table that exists in Database A (e.g. SELECT * FROM creator.cause LIMIT 100;).
3. In the results toolbar, click the ... menu → Switch database... and select a different database (Database B).
4. Run the same query (or queries on other tables).
5. The query fails with ERROR 42P01: relation "..." does not exist.
6. Try to switch back to Database A using the same menu — the binding remains stuck on Database B.
7. Other tables/queries in the same notebook are also affected.

Expected behavior
Switching the database should be fully reversible. Queries should always run against the currently selected database. Closing and reopening the notebook or restarting VSCodium should restore the original database binding.

Screenshots

Desktop (please complete the following information):

• OS: Fedora 44
• Editor: VSCodium
• Extension: ric-v.postgres-explorer (PgStudio / NexQL)
• Version: 1.4.1

Additional context

• Behavior is inconsistent: sometimes closing the .pgsql file and reopening it restores the original database; other times the stuck state persists even after restarting VSCodium.
• Duplicating the database connection was a workaround that restored functionality.
• The issue affects the entire notebook session, not just the current query.

[github-actions]

Welcome to the project, @jcalfee! 👋
Thank you for taking the time to improve our codebase. We really appreciate the effort.

[ric-v]

Hi @jcalfee, thank u for sharing a detailed bug report, this is really helpful and makes the product more robust.
We'll get a fix ready ASAP. We are working on a 2.0 release with few rebranding to the core platform. It's due for release soon and the fix will definitely be included.
Please wait for the next release, thanks again.

[jcalfee]

Thanks! The placement of the switcher really has me thinking. One of the things that would make this super powerful is to be able to connect to multiple databases in the single page. It gets to a point where I try to manage things like replication and there's queries that really need to run on both sides. I think you're placing the database connections which are on the query level is a fantastic move. As always, some art is required to keep this from being confusing but wow this is the right architecture in my opinion. One option may be to allow for more flexible drag and drop that would allow of mixing different database connections / databases into a single .pgsql file.

I see you've made huge progress on this release. There are some other small things but They are pretty obvious and I'll just wait for your 2.0 release. They may be covered. Just to mention it briefly:

1. formatted JSON view option (many json / jsonb types are very long and benefit from a nice json formater lib / perhaps with folding).
2. It assumes I'm using MS SQL, but I'm using Postgres.
3. I put in a VLLM endpoint with my own hosted model, but it still says API requests failed Status 404 even though the custom endpoints for both chat and notbook are configured for open AI-compatible and "test" works confirming it is reachable and API compatible.
4. I can save as Markdown but it's kind of a shame that I can't send it as Markdown directly to the clipboard; I see you already have copy to clipboard (csv) and that is working.

... Other small things but more obvious so I'm sure I don't need to mention (like transpose only transposes once not back) ...

Very impressive architecture though. It feels like it's built using something like MDX (markdown xml / evidence.md is a good example). Grok says your not using MDX. If there were MDX components one day, some evidence.dev reporting components, then arbitrary text and formatting, this is not far from making actual documented web pages for apps that could perform powerful db admin functions. There's so many configuration variations though, to get there, I think something like free-formed markdown and interlinked MDX components are going to be necessary.