用Ollama生成SQL：轻松查询PostgreSQL所有表名的完整实践

你如果同时接触过 Ollama 和 PostgreSQL，多半会跟我一样遇到一个尴尬瞬间：本地模型跑起来了，数据库也连上了，结果翻来覆去不知道该查哪张表，或者连当前库里到底有哪些表都记不全。手头那台机器明明装了 Ollama，为什么不直接让它帮我把“查询所有数据表名称”这件事做了？这篇文章就把我折腾这条完整链路的过程写出来，包括 PostgreSQL 里查表名的几种正统写法、Ollama 的 Prompt 设计、以及把两者串起来的脚本方案。适合正在玩本地模型、同时需要管理 PostgreSQL 的朋友，也适合想用大模型辅助日常数据库操作的人。

1. 先搞明白：这个场景到底在解决什么问题

说实话，“Ollama PostgreSQL 查询所有数据表名称”这个标题乍一看有点让人摸不着头脑——Ollama 本身不连数据库，PostgreSQL 也不会主动去调用 Ollama。实际发生的事情是：你用 Ollama 跑了一个本地大模型，然后想通过自然语言对话，让模型帮你生成一段 SQL，这段 SQL 的作用是查询当前 PostgreSQL 数据库里所有数据表的名称。

为什么会有这个需求？原因很现实。我接手过一些历史项目，数据库里有几十张甚至上百张表，表名不是按照tb_user、tb_order这种清晰规则命名的，而是像t_2023_crm_data、sync_log_bak_0912这样五花八门。想快速了解库里有什么，最直接的办法就是跑一条查询所有表名的 SQL。可这个 SQL 不是人人都会写，尤其是不常碰 PG 的人，第一反应往往是去搜“PostgreSQL show tables”，结果发现 PG 根本没有show tables这个命令。这时候，本地 Ollama 里那个模型就成了最好的排障搭子——你直接问它“PostgreSQL 怎么查所有表名”，它基本能给你一个能跑的答案。

这个场景还有一个更实用的落地方式：你在 Python 或其他代码里把自然语言问题发给 Ollama 的接口，让模型生成 SQL，然后程序自动去 PostgreSQL 执行并返回结果。这就是一个非常轻量的“本地数据库助手”。不需要联网，不需要把敏感数据传到云端，而且模型权重和数据库全部在你自己的机器上。

所以这篇内容不仅仅是教你一段 SQL，而是把“自然语言到 SQL”这个完整的本地闭环跑通。下面我会从环境准备开始，一步一步讲。

2. 环境准备：Ollama 和 PostgreSQL 先跑起来

2.1 Ollama 安装与模型下载

Ollama 的安装本身没什么难度，去官网下载对应系统的安装包就行。Windows 和 macOS 都有图形化安装程序，Linux 用一条curl -fsSL https://ollama.com/install.sh | sh也能搞定。只是国内网络环境下，模型下载经常慢到怀疑人生。我个人的建议是绕开官网模型仓库，直接使用国内一些云厂商提供的镜像加速地址。具体做法是在系统环境变量里设置OLLAMA_MODELS指向你的模型存储目录，同时配置镜像源变量，然后重新启动 Ollama 服务。这样再执行ollama pull qwen2.5时，速度能提升几个数量级。需要注意的是，不同镜像源的地址可能会变，最好去模型的官方项目页或者社区看看当前可用的地址。

模型选型上，如果你主要目的是生成 SQL，不要一上来就选那种几十B的大家伙，除非你的显卡显存很充裕。我用 8GB 显存跑过qwen2.5:7b，效果已经不错；如果你只有 CPU，那qwen2.5:3b或者更小的qwen2.5-coder:1.5b也可以应急。关键是模型必须经过代码/指令微调，纯基座模型回答会非常随性，不适合这种任务。

2.2 PostgreSQL 安装与连接准备

PostgreSQL 的版本选择，我个人建议直接上 16 或 17，功能更全，性能也更好。Windows 下用官方安装包一路下一步即可，注意安装过程中会让你设置超级用户postgres的密码，这一步不要跳过，不然后面连接的时候会卡在认证上。Linux 下用包管理器安装（比如apt install postgresql）也很方便，装完之后需要手动初始化数据目录并启动服务。

装好之后，我习惯用psql命令行先做一次验证。Windows 下安装包会把psql加到 PATH 里，Linux 下可能需要sudo -u postgres psql切到系统用户。连接命令很简单：

psql -U postgres -h localhost -p 5432

输入密码后看到这样的提示符就说明连上了：

postgres=#

如果这一步报认证错误，先检查pg_hba.conf里的认证方式是不是md5或scram-sha-256，默认的trust虽然能免密，但不够安全，我自己只在本地测试环境才用 trust。

2.3 我建议的模型选型

前面提到过，这里再展开一点。Ollama 模型库里跟代码相关的有不少，比如qwen2.5-coder、deepseek-coder、codellama。但因为你只是生成一小段查询表名的 SQL，通用对话模型也完全够用。我实测下来，qwen2.5:7b对 PostgreSQL 的语法掌握得很准，尤其是pg_tables这种经典视图，它基本能直接给出正确写法。

如果你只是临时问一个问题，运行ollama run qwen2.5:7b然后输入中文问题就行。但如果你想把它做成可复用的工具，还是建议用 API 方式调用，这就引出了后面的内容。

3. PostgreSQL 查询所有表名的四种正规方法

PostgreSQL 没有 MySQL 那种SHOW TABLES命令，但有好几种等价方案。以下是我踩过坑之后整理出的四种常用方法，每一种都有自己的适用场景。

3.1 psql 命令行：最省事的 \dt

如果你只是人肉连上去看有哪些表，直接在 psql 里敲：

\dt

它会列出当前数据库的所有表、视图、序列也不算在里面。输出大概是这样：

List of relations Schema | Name | Type | Owner --------+------+-------+-------- public | users | table | postgres public | orders| table | postgres

这个命令的底层其实是去查系统目录，但它会额外格式化，适合人看。缺点是它不是一个标准 SQL，你没法在其他客户端或者程序里直接用。如果你想知道publicschema 下有哪些表，\dt public.*也可以，但没必要，因为默认就在 public。

3.2 pg_tables 视图：最推荐的标准方式

pg_tables是 PostgreSQL 系统目录里一个现成的视图，专门用来展示表信息，官方文档明确推荐。查询所有用户表的写法是：

SELECT tablename FROM pg_tables WHERE schemaname = 'public';

这里schemaname = 'public'是关键。PostgreSQL 的默认 schema 是 public，所有不带 schema 前缀创建的表都会进到这里。如果你不限定 schema，查询结果会包含pg_catalog和information_schema里的系统表，那真就一眼望不到头了。

这个方式好在哪里？它是纯 SQL，任何语言、任何连接工具都能执行，而且查询速度快。它还包含表的所有者（tableowner）和是否有索引等信息，如果你后续不仅要名字，还想顺便看看哪些表是空表，可以在pg_tables基础上继续 join 别的目录。

3.3 information_schema.tables：跨数据库的 ANSI 标准

如果你以后有可能把代码从 PostgreSQL 迁移到其他数据库，用information_schema更保险，因为它是 SQL 标准的一部分，MySQL、SQL Server 也支持。写法是：

SELECT table_name FROM information_schema.tables WHERE table_schema = 'public' AND table_type = 'BASE TABLE';

注意这里用的是table_schema而不是schemaname，字段名不一样。还有table_type要过滤成BASE TABLE，否则会把视图也带进来。视图在information_schema里的类型是VIEW，有时候你确实也想看视图，那就不用加这个条件。

两种方式我都用过很多次，总的来说：日常查询用pg_tables，因为信息更全、更贴近系统本身；做跨库兼容或者写教学文章时用information_schema。

3.4 只想看名字的行家做法：字符串拼接

上面的方法返回的是多行，每行一个表名。但有时你只想要一个以逗号分隔的列表，方便复制到其他工具里或者快速扫一眼。这时候可以这样写：

SELECT string_agg(tablename, ', ' ORDER BY tablename) FROM pg_tables WHERE schemaname = 'public';

输出就是一行：

orders, products, user_profiles, ...

这个技巧在你想把所有表名当参数传给某个脚本时特别有用，省得再去处理多行结果。string_agg是 PostgreSQL 特有的聚合函数，在别的数据库里不一定有，但因为是 PG 的项目，这个没问题。

4. 让 Ollama 生成 SQL：从命令行到 API 调用

环境就绪以后，下面就是重头戏：怎么让 Ollama 帮你完成“查询所有数据表名称”这件事。

4.1 直接在终端里问模型

最简单的路径，运行：

ollama run qwen2.5:7b

然后输入：

PostgreSQL 怎么查询当前所有数据表名称？

它会给出类似这样的回答：

SELECT tablename FROM pg_tables WHERE schemaname = 'public';

并且附带一两句解释。这个方式适合个人救急，但有两个问题：一是模型每次回答的格式不固定，可能带解释、带 Markdown 代码块标记，不利于自动化处理；二是你还是要自己复制结果去 psql 执行。虽然步骤简单，但作为“工具”还不算完整。

4.2 用 API 把自然语言变成 SQL

为了让整个流程可复用，我选择调用 Ollama 的 HTTP 接口。默认情况下，Ollama 监听在localhost:11434。你可以先验证一下：

curl http://localhost:11434/api/tags

能看到已下载模型列表，说明服务正常。接下来用/api/generate接口来提问：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "请为 PostgreSQL 写一条 SQL，查询当前数据库 public schema 下所有数据表的名称。只输出 SQL，不要任何解释。", "stream": false }'

返回的 JSON 里response字段就是模型生成的文本。注意我在 Prompt 里加了“只输出 SQL，不要任何解释”这个约束。这一步非常关键，如果你不加，模型很可能把解释和代码混在一起，后面拿这段文本去解析 SQL 时就会很痛苦。

如果你更习惯用聊天接口，也可以用/api/chat，参数结构差不多。实际开发中，我用 Python 的requests库更多一些，代码写在下面。

4.3 写一个小脚本，把问问题和执行结果打通

光生成 SQL 还不行，我们要的是最终的表名列表。于是我写了一个几十行的 Python 脚本，流程是：先把问题发给 Ollama，拿到 SQL 后用psycopg2连接 PostgreSQL 执行，再把查询结果打印出来。这样你在终端里输入一句大白话，就能直接看到数据库里的表名。

import requests import psycopg2 OLLAMA_URL = "http://localhost:11434/api/generate" prompt = """ 你是 PostgreSQL 数据库专家。请根据用户的问题生成一条 SQL。 用户问题：查询当前数据库中 public schema 下所有数据表的名称。 要求：只输出 SQL 语句，不要加任何解释、前后缀或 Markdown 代码块标记。 """ resp = requests.post( OLLAMA_URL, json={ "model": "qwen2.5:7b", "prompt": prompt, "stream": False, }, timeout=120, ) resp.raise_for_status() sql = resp.json()["response"].strip() print("模型生成的 SQL:", sql) # 连接 PostgreSQL 并执行 conn = psycopg2.connect( host="localhost", port=5432, dbname="testdb", user="postgres", password="你的密码", ) cur = conn.cursor() cur.execute(sql) rows = cur.fetchall() for row in rows: print(row[0]) cur.close() conn.close()

运行这个脚本，你会看到模型先生成 SQL，然后在同一段脚本里执行查询，直接把表名打印出来。

这段代码里有几个细节要特意说下。第一，timeout=120是因为本地模型在 CPU 上推理可能比较慢，尤其模型体积稍大时，给足等待时间避免请求超时。第二，response里的文本可能包含换行或空格，我用strip()去掉首尾空白。第三，也是特别容易翻车的：有些模型会不听话，在 SQL 外层套上 ```sql 标记，这时不要直接执行，可以先做一次清洗，去掉代码块标记。

5. 实测记录：我踩过的几个典型坑

实践出真知，我把实际跑这个链路时遇到的几个典型情况写出来，给大家做个参考。

5.1 模型输出“解释+代码”的混合体

第一次测试时，我用的 prompt 没有加“只输出 SQL”的限制，模型给出的是：

在 PostgreSQL 中，您可以使用以下查询来获取 public schema 下的所有表名： SELECT tablename FROM pg_tables WHERE schemaname = 'public';

这段文本看着很友好，但程序没法直接执行。我加了一句“只输出 SQL 语句，不要任何解释”之后，它才老实起来。如果你收到的回复还是带了解释，可以用简单的正则把代码块提取出来：

import re sql = re.sub(r"```sql\s*|\s*```", "", sql).strip()

这个正则看情况用，最好的办法还是从一开始就约束模型。

5.2 PostgreSQL 返回结果为空，问题多半出在 schema

我之前有一次在数据库里明明建了好几张表，但执行SELECT tablename FROM pg_tables WHERE schemaname = 'public'却是空结果。排查了半天，发现连接的是另一个数据库实例，或者表建在了自定义 schema 下。比如有人建库时执行了CREATE SCHEMA business;，然后建表也用了business.user_info，那public下当然查不到。解决办法是把条件改成WHERE schemaname = 'business'，或者干脆不限定 schema，再在结果里自己分辨。如果表分布在多个 schema 下，可以这样看总览：

SELECT schemaname, tablename FROM pg_tables WHERE schemaname NOT IN ('pg_catalog', 'information_schema') ORDER BY schemaname, tablename;

5.3 表名大小写问题：查询结果对，但实际连不上

PostgreSQL 对表名的大小写处理跟 MySQL 不一样。如果建表的时候用的是大写或混合大小写，且没有加引号，PostgreSQL 会自动转成小写。但如果你建表时显式加了引号，比如CREATE TABLE "UserInfo" (...)，那表名就是大小写敏感的。查询出来的名字可能是UserInfo，你执行SELECT * FROM UserInfo也会报错，必须写成"UserInfo"。这个跟模型生成 SQL 没关系，但挺容易误导人，我提一句，免得你在验证结果时怀疑自己的 SQL 写错了。

5.4 Ollama 的 500 internal server error

热词里很多人提到ollama run qwen报500 internal server error: llama-server process。我也遇到过，通常有两种情况：一是本地显存或内存不够，加载大模型时进程被杀；二是模型文件损坏。如果是第一种，换小一号的模型，或者关闭其他占内存的程序；如果是第二种，删掉模型重新ollama pull一次。这个错误不属于“查询表名”的常规流程，但既然你在跑 Ollama，遇到它也别慌，我的建议是先看 Ollama 的日志，默认在~/.ollama/logs下，里面会写明 OOM 还是其他异常。

6. 常见问题与避坑速查

下面把我实际遇到的问题整理成一张表，方便你对着排查。

这张表里的前两行虽然看起来跟“查表名”没有直接关系，但都属于整条链路里绕不开的痛点，尤其是 Ollama 下载慢和模型进程崩溃，几乎每个人都会遇到。

最后再分享一个我自己现在正在用的小技巧：与其每次都让模型现写 SQL，不如先把一个“查询所有表名”的通用 SQL 固化成一个 PostgreSQL 函数，比如：

CREATE OR REPLACE FUNCTION list_tables(schema_name text DEFAULT 'public') RETURNS TABLE(tablename text) AS $$ BEGIN RETURN QUERY SELECT pg_tables.tablename::text FROM pg_tables WHERE pg_tables.schemaname = schema_name; END; $$ LANGUAGE plpgsql;

然后你只需要让 Ollama 学会调用SELECT * FROM list_tables();这一个入口，无论遇到什么数据库，模型都不用自己去拼复杂的元数据查询。这样既减少了模型犯错的概率，也让整个闭环更稳定。我在实际项目中用这个方式跑了两个多月，基本没再出现过因为 SQL 写错而报警的情况。如果你也在折腾 Ollama 和 PostgreSQL 的组合，可以按照上面的思路搭一套属于自己的“自然语言查表助手”，相信我，你会觉得之前的反复手查表名太浪费时间了。