@avastms 哈，组装得确实有些怪异，主要还是早先他们迭代来回改了好多年，如果不是用 Python 的话可能已经跪了；另外 Postgres 自己也是攒了那么多年门槛太高了，之前我的帖子里也讨论过怎么轮的问题。下一步用 Rust 重写 I/O 层还算是比较可行的计划。

@yxt 啊有意思的需求！让我想到了之前给车企外包时，用 U 盘拷 pip 包的情景……理论上应该是可以手动实现的，不过能否获得上游支持不好说，我明天试试，如果简单就回复那个 issue 了。GINO 就比较惭愧了，没时间做新版本了，但既然 SQLAlchemy 已经支持 asyncpg 了……

@fgwmlhdkkkw 找到了： https://github.com/edgedb/edgedb/blob/7f1a522a033eaa699e65c628304504da8b007146/edb/server/args.py#L507

@fgwmlhdkkkw 可以禁，我记得是个环境变量叫 INSECURE_DEV_MODE ，但我忘了加哪了，我先用手机找找试试

@Braisdom 👍👍值得尊敬的项目

@masterclock 抱歉现在还没有，不过有专门同事负责 Go 这一块，虽然他也要做 cloud ，但 Go query builder 估计也不会拖太久。

@bnm965321 哇那还是 2018 年那会儿吧，文档后来改了不少，老板跟我说你们先把 tutorial 翻译了吧，然后 server error message 也可以搞一搞。 @DaisyDai 最近把《 EdgeDB 易经》翻译完了

@emeab 嗯……目前官方客户端库支持 Python 、TypeScript 、Deno 和 Go ，其中 TypeScript 有 query builder ，目标是完全替代 ORM 。Rust 客户端现在是半成品，目前主要用在自家的 CLI 工具里。可能你说的库还有其他层的？

@FrankHB 虽然 PL 的话题超过我的认知太多了，但我还是要说，有理想总是好的。我先尝试跟老板在这个角度聊一下吧，看他们野心有多大。看了你的 GitHub 和 mailing list ，你在参与维护 C++？

@FrankHB 感谢码字！我不敢相信我在做中文的阅读理解题归纳总结中心思想……才疏学浅，望指正！你是不是说，通过类比 I/O 在工业 PL 中的错位实现无法反应底层计算作用这一现象，尝试说明传统 PL 的方式方法无法对 DB 领域的查询语言做出革命性的突破，虽然可以超越门槛很低的 SQL ，但真正有意义的方法论级别的创新，还需懂 DB 的人从如何传递和撬动计算作用的角度加以深挖。

打错了，EdgeDB 至少有 SDL ，declarative schema definition language

@FrankHB 老哥，您这高度拔得有点儿忒高了，完全超过了我能回复的范畴了……待我翻译成英文给我们老大看看。你的大意是不是说，现在的 DBMS 有些剑走偏锋了，无法把控好诸如文件系统级别的实现，虽然也能通过关系模型实现出基本能用的 RDBMS ，但始终还是没有能完整服务好原始需求，至于 LP 则更是没人关心，更别提很多 DBMS 连 DL 都没有（ EdgeDB 至少有 DDL ），所以发展成现在这样不足为奇，但也无能为力，因为要实现理想中的 DB ，还需打破现有技术的束缚——我不知道怎么说——按需求从比如 SSD 或 CPU 架构特性着手，技术栈从下往上一直堆到 DSL 层面的逻辑数据定义和操作语言，做出一个适用性更好的 DBMS ？

@adoal 哈，感谢关注！能改 pg 固然是一条捷径（相对于自己轮），然而工作好像也不少，EdgeQL 的 parser 后面还有一个编译器，通过 EdgeQL schema 上下文输出 SQL ，改到 pg 里这块要么输出 SQL AST 然后进 pg 后续的编译 planner 什么的继续跑，要么就得再多解耦 pg 的一些部分，然后重写 EdgeQL 编译器输出 pg 的命令，还得适配 planner 什么的。感觉前者就是用 C （或 Rust ）重写了现在的一些 Python 代码，和并进 pg 进程里，后者除了“存储引擎”基本上都是自己写了，所以还是想自己轮。嗨，这都是我自己瞎 yy ，就算重写也得找数据库大牛来撑，再说 EdgeDB 能发展到什么程度还说不定呢。

@fds 感谢！我会动员全家老小尽快制作中文字幕发 B 站的。你后面碰到的这种情况怎么说的，纯粹实用角度可能也没毛病，有时候只能是自己怀揣一颗追求技术的心，把眼前的事情做完再说。但总感觉如果都这样的话，有点劣币驱逐良币的意思……

@Itoktsnhc 啊对的，目前确实在推 EdgeDB ，但我确实有（特别长远不切实际的）想法，如果 EdgeDB 能被市场接受，那就回去攒人用 Rust 写一个咱自己的 EdgeQL 后端。关于兼容层，EdgeDB 作为 EdgeQL 的唯一实现，虽然有 IR ，但后端是强依赖于 Postgres 的，可以用 RDS Aurora 什么的，但再别的就不行了。

@loginv2 是我软文写得太软了吗？ EdgeDB 了解一下！声明式 schema 、内置 migration 、完备周边配套设施（客户端、CLI 以及现代开发工作流），最重要的是有杀手锏 EdgeQL ，一次性解决 SQL 各种顽疾，当天即可下地走动。

@Chad0000 @charlie21 嗯嗯，嗯！对，有道理！感谢分享！
@cmdOptionKana GraphQL 只能算是接口 spec 吧，感觉离查询语言还是稍有距离。NoSQL 们怎么说的，不太好一概而论，各自都有擅长解决的问题，不过确实没有能看到充分替代关系模型的解决方案。

https://pgjones.gitlab.io/quart/ 对标 Flask