Use in your IDE
Th Postgres Language Server has first-class LSP support to seamlessly integrate into your favorite editor.
VSCode
The language server is available on the VSCode Marketplace. It's published from this repo.
Neovim
Installation via Mason (Recommended)
The easiest way to install the language server is via Mason:
:MasonInstall postgres-language-server
Then configure nvim-lspconfig to use it:
require('lspconfig').postgres_lsp.setup{}
Manual Installation
- Download the binary for your platform from the releases page
- Place it in your
$PATH - Configure
nvim-lspconfig:
require('lspconfig').postgres_lsp.setup{
cmd = { "postgres-language-server", "lsp-proxy" },
}
For more details, see the nvim-lspconfig documentation.
Troubleshooting
If the language server isn't working:
-
Check that the binary is executable:
bash which postgres-language-server postgres-language-server --version -
Check LSP status in Neovim:
vim :LspInfoThis shows if the server is attached to your buffer. -
Check the logs:
vim :LspLogLook for errors related topostgres_lsp. -
Verify your file is recognized as SQL:
vim :set filetype?Should outputfiletype=sqlfor.sqlfiles.
Emacs
The language client is available through lsp-mode. For more details, refer to their manual page.
Cursor
The language server is available on the Open VSX Registry. Install it from the extensions panel in Cursor.
Zed
The language server is available as an Extension. It's published from this repo.
Note
Is there a extension for an editor that is not listed here? Please file a PR and we will be happy to add it to the list
Sublime Text
See install instructions.
Integrate in an editor extension
Is your favorite editor missing? Thanks to the language server protocol, integrating the Postgres Language Server protocol should be straightforward.
Use the LSP proxy
The CLI has a command called lsp-proxy. When executed, we will spawn two processes:
- a daemon that does execute the requested operations;
- a server that functions as a proxy between the requests of the client - the editor - and the server - the daemon;
If your editor is able to interact with a server and send JSON-RPC request, you only need to configure the editor run that command.
Use the daemon with the binary
Using the binary via CLI is very efficient, although you will not be able to provide logs to your users. The CLI allows you to bootstrap a daemon and then use the CLI commands through the daemon itself.
If order to do so, you first need to start a daemon process with the start command:
postgres-language-server start
Then, every command needs to add the --use-server options, e.g.:
postgres-language-server check --use-server --stdin-file-path=dummy.sql
Note
If you decide to use the daemon, you’re also responsible to restart/kill the process with the stop command, to avoid having ghost processes.
Caution
Operations via the daemon are significantly slower than the CLI itself, so it’s advised to run operations only on single files.
Daemon logs
The daemon saves logs in your file system. Logs are stored in a folder called pgls-logs. The path of this folder changes based on your operative system:
- Linux:
~/.cache/pgls; - Windows:
C:\Users\<UserName>\AppData\Local\supabase-community\pgls\cache - macOS:
/Users/<UserName>/Library/Caches/dev.supabase-community.pgls
For other operative systems, you can find the folder in the system’s temporary directory.
You can change the location of the pgls-logs folder via the PGLS_LOG_PATH variable.