TabularisDB/tabularis

Describe the bug On a PostgreSQL connection, when you confirm the schema selection for the first time with two or more schemas (e.g. "Select All" with public and sales), one of the schemas shows up empty in the sidebar: TABLES (0), No tables found, ROUTINES (0), while the other one is loaded correctly. The backend did return the data, so the problem is only in the frontend state. The schema stays empty until you collapse and expand it again, which triggers a new load. It happens with both the built-in PostgreSQL driver and the PostgreSQL plugin. To Reproduce Create a PostgreSQL database with at least two schemas that have objects, for example: CREATE TABLE customers (id serial PRIMARY KEY, name text); CREATE TABLE orders (id serial PRIMARY KEY, customer_id int REFERENCES customers(id)); CREATE FUNCTION add_tax(amount numeric) RETURNS numeric LANGUAGE sql AS $$ SELECT amount * 1.22 $$; CREATE SCHEMA sales; CREATE TABLE sales.invoices (id serial PRIMARY KEY, number text); Add a new c

Describe the bug The in-app updater is disabled for installs managed by a package manager, but detection (src-tauri/src/updater/installation_source.rs) only covers Snap (SNAP), Flatpak (FLATPAK_ID), the AUR tabularis-bin package and the build-time PACKAGE_MANAGER_* variables. Installs from the channels the README recommends are not detected: Homebrew cask (brew install --cask tabularis) on macOS WinGet (winget install Debba.Tabularis) on Windows so those users get the in-app updater, which replaces the app behind the package manager's back (brew/winget then report a stale version or try to upgrade again). Expected behavior Homebrew-cask and WinGet installs show "Updates managed by …" and the in-app installer is disabled, like Snap/Flatpak/AUR. Where to start installation_source.rs: e.g. detect a Caskroom receipt (/opt/homebrew/Caskroom/tabularis, /usr/local/Caskroom/tabularis) on macOS; for WinGet, either inject PACKAGE_MANAGER_* in the winget manifest/installer or check the winge

Describe the bug --debug is documented in tabularis --help as: Enable debug logging (including sqlx queries) but the log level is hard-coded to Info in src-tauri/src/lib.rs (log::LevelFilter::Info), RUST_LOG is not read, and --debug only opens DevTools and re-enables the native context menu. There is no way to get debug-level logs when troubleshooting a connection problem. Expected behavior --debug raises the logger to Debug (including sqlx statements), or the help text is corrected. Honouring RUST_LOG when set would be a bonus. Where to start src-tauri/src/cli.rs (Args::debug) and src-tauri/src/lib.rs where init_logger(…, log::LevelFilter::Info) / log_level are set. src-tauri/src/logger.rs for the in-memory buffer that Settings → Logs shows. Acceptance criteria tabularis --debug shows debug entries (and sqlx queries) in Settings → Logs and stderr. Without --debug the level stays Info. Contributor notes Follow the repo rules in .rules/ (TypeScript, React, Rust, testing). A

Describe the bug When the app language is Auto (the default), the AI analysis in Visual Explain is always generated in English, even if the UI is shown in another language detected from the system. src/i18n/language.ts: export function getAiExplanationLanguage(language: AppLanguage): string { const fallBackLanguage = "English"; if (language === "auto") return fallBackLanguage; … } To Reproduce OS language Italian, Tabularis language left on Auto (UI is in Italian). Visual Explain → AI tab: the analysis is in English. Selecting "Italiano" explicitly gives Italian. Expected behavior With Auto, use the language i18next actually resolved (i18n.resolvedLanguage), falling back to English only if it isn't supported. Where to start src/i18n/language.ts getAiExplanationLanguage and its callers (e.g. ExplainAiAnalysis.tsx, the AI explain prompt) — pass the resolved language when the setting is auto. Acceptance criteria Auto + Italian UI → Italian analysis; Auto + unsupported l

Describe the bug PostgreSQL allows overloaded functions (same name, different arguments). The definition lookup used by View Definition and Edit filters by schema and name only and takes LIMIT 1 (src-tauri/src/drivers/postgres/mod.rs, get_routine_definition): SELECT pg_get_functiondef(p.oid) FROM pg_proc p JOIN pg_namespace n ON p.pronamespace = n.oid WHERE n.nspname = $1 AND p.proname = $2 LIMIT 1 With overloads, an arbitrary one is shown or edited, whichever entry is clicked in the sidebar. Parameters and Run… likely have the same ambiguity. To Reproduce CREATE FUNCTION f(a int) RETURNS int … and CREATE FUNCTION f(a text) RETURNS text …. The sidebar lists both; View Definition on either may show the same body. Expected behavior Each overload is identified by its signature (e.g. oid or pg_get_function_identity_arguments) and View/Edit/Run act on the clicked one. Where to start src-tauri/src/drivers/postgres/ routine listing and definition queries; RoutineInfo would need an id