Stored Procedures & Routines
Tabularis manages stored procedures and functions (collectively called routines) from the Explorer sidebar. Beyond browsing definitions and parameters, you can run a routine with parameters, create one from a dialect-aware template, edit its definition, and drop it — the same full lifecycle it offers for tables and views.
Management is gated on a routine_management driver capability, enabled out of the box for PostgreSQL and MySQL/MariaDB. Plugin drivers can opt in through their manifest (see Driver Support).
Browsing Routines
Routines appear in the sidebar under the Routines section for each database or schema. They are grouped by type:
- Functions — routines that return a value.
- Procedures — routines that perform actions without a direct return value.
Each group is collapsible. The routine name and type icon help distinguish functions from procedures at a glance.
PostgreSQL Overloads
PostgreSQL allows several functions with the same name and different arguments. Since v0.28.0 each overload is labelled with its signature, for example f(a integer, b integer), in the sidebar and the command palette, and View Definition, the parameter list, Run…, Edit and Drop act on the exact overload you clicked. Before, overloads showed as identical rows and these actions picked whichever came back first. Plugin drivers receive the signature too, so a dialect with overloading can use it.
Viewing Parameters
Expand a routine in the sidebar to see its parameter list. Each parameter shows:
| Field | Description |
|---|---|
| Name | Parameter name |
| Data type | The SQL type (e.g., INTEGER, VARCHAR, JSONB) |
| Mode | Direction badge: IN, OUT, or INOUT |
Parameters are listed in ordinal order as defined in the routine signature.
Viewing the Definition
Double-click a routine — or right-click → View Definition — to open the full routine SQL in a read-only editor tab. This shows the complete CREATE FUNCTION or CREATE PROCEDURE statement as stored by the database.
The definition is fetched directly from the database catalog, so it always reflects the current state of the server.
Running a Routine
Video unavailable
Right-click a routine → Run…. A modal titled Run <name> collects one input per IN/INOUT parameter (the Command Palette only opens a routine's definition):
- A NULL checkbox to pass
NULLexplicitly. - A raw value toggle — on by default for numeric types — that controls whether the value is inlined verbatim or quoted as a literal.
Clicking Open in Editor builds the invocation script and opens it in a new editor tab without running it, so you can review the call before executing it (since v0.27.0; earlier versions ran it straight away):
- MySQL / MariaDB — functions run as
SELECT fn(...) AS result;. For procedures,OUT/INOUTparameters are threaded through session variables (SET @p = …;forINOUTinputs, thenCALL routine(@p); SELECT @p;), and the multi-statement script runs on a single pooled connection so the session variables survive across statements. - PostgreSQL — functions run as
SELECT * FROM fn(...)(pureOUTparameters are left out of the call), so a set-returning function comes back as a full result set in the grid. Procedures run asCALL proc(...), withOUTparameters passed asNULLplaceholders.
Creating a Routine
Click the + button on the Routines section header (tooltip New routine) and choose New procedure or New function. Tabularis opens the editor pre-filled with a dialect-aware starter template:
- MySQL / MariaDB — a
DELIMITER-wrappedCREATE PROCEDURE/CREATE FUNCTIONskeleton. - PostgreSQL — a
CREATE OR REPLACE FUNCTIONorCREATE OR REPLACE PROCEDUREskeleton (LANGUAGE plpgsql) with dollar-quoting.
Since v0.28.0 the + button is also on Routines sections nested under a schema (PostgreSQL) or under one of several databases (MySQL / MariaDB multi-database connections), and the new routine targets the schema or database the section belongs to. Before, only the connection-level Routines section had it.
Fill in the body and run it like any other statement.
Editing a Routine
Right-click a routine → Edit. Tabularis opens a re-runnable script that recreates the routine in place:
- MySQL / MariaDB — the
SHOW CREATEoutput wrapped in aDROP … IF EXISTS+DELIMITERblock. - PostgreSQL — the definition from
pg_get_functiondef, which is already aCREATE OR REPLACE.
Dropping a Routine
Right-click a routine → Drop. A Drop routine confirmation dialog is shown before the statement runs. On PostgreSQL, the statement names the exact identity signature from pg_get_function_identity_arguments, so it never drops the wrong function when several share a name. Since v0.28.0 Drop also works on an overloaded name, using the signature of the row you clicked; before, it refused overloaded names.
Context Menu Actions
Right-click any routine in the sidebar:
| Action | Description |
|---|---|
| Run… | Opens the Run modal to build the call with parameters and open it in the editor for review |
| View Definition | Opens the routine SQL in a read-only tab |
| Edit | Opens a re-runnable script to change the definition |
| Drop | Drops the routine after a confirmation |
| Copy Name | Copies the routine name to the clipboard |
The Run… / Edit / Drop actions appear only when the connection's driver declares the routine_management capability.
Driver Support
| Feature | PostgreSQL | MySQL / MariaDB | SQLite | Plugin drivers |
|---|---|---|---|---|
| List routines | Yes | Yes | Not applicable* | Per manifest |
| View definition | Yes | Yes | Not applicable* | Per manifest |
| View parameters | Yes | Yes | Not applicable* | Per manifest |
| Run / Create / Edit / Drop | Yes | Yes | Not applicable* | Opt-in** |
*SQLite does not support stored procedures or functions at the SQL level.
**For plugin drivers the four management methods are optional JSON-RPC calls. A plugin only overrides what its dialect needs; when a method isn't implemented, the host falls back to generic SQL — for example a bare CREATE PROCEDURE|FUNCTION my_routine() BEGIN … END template, and the routine definition for Edit — so basic routine management works even without a custom implementation.
Data Model
Each routine is represented as:
- RoutineInfo: name, type (
PROCEDUREorFUNCTION), and optional definition text. - RoutineParameter: name, data type, mode (
IN/OUT/INOUT), and ordinal position.
This metadata is queried from INFORMATION_SCHEMA.ROUTINES and INFORMATION_SCHEMA.PARAMETERS (or the driver-equivalent catalog views).
Related
- Triggers — managed alongside routines from the same sidebar accordion pattern.