编程与软件工程wiki.postgresql.org编辑精选
PostgreSQL 常见错误
Common mistakes in PostgreSQL
2019 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 PostgreSQL 官方 Wiki 上的经典页面，列举了开发者在使用 Postgres 时常见的错误做法，例如滥用 varchar(n) 的长度限制、误用 CURRENT_TIME、使用表继承等，并解释了为什么这些做法不好、应该用什么替代。页面多次登上 HN 首页，是数据库使用者的必读参考。
为什么经久不衰：它由社区持续维护，用'不要做什么'的方式直击实际开发中的坑，无论何时使用 Postgres 都能避免踩雷。
HN 评论精选
作者惊讶于字段长度限制并不影响存储和性能，解除了以往的性能焦虑。
'varchar（不带 n）或 text 类似，只是没有长度限制。如果把同样的字符串插入这三种字段类型，占用的空间完全一样，性能上也没有可测量的差异。'——真的吗？每次我在 Django 里建 CharField 都会绞尽脑汁猜一个最佳长度来优化性能，原来用不限长度的 TextField 没有任何区别，好消息。
polote查看英文原文
> varchar (without the (n)) or text are similar, but without the length limit. If you insert the same string into the three field types they will take up exactly the same amount of space, and you won't be able to measure any difference in performance. Seriously ? everytime I create a django charfield I try to guess in my head what is the best length for this field to optimize for performance, but sounds like using unlimited length (textfield) field doesn't make any difference. Good news
用超长姓氏的真实例子说明随意设置 varchar 长度限制的风险。
'如果你确实需要限制长度的文本字段，varchar(n) 很好；但如果你随意选个长度，比如给姓氏字段设 varchar(20)，那将来当 Hubert Blaine Wolfeschlegelsteinhausenbergerdorff 来注册你的服务时就会出生产事故。'
jchampem查看英文原文
> If what you really need is a text field with an length limit then varchar(n) is great, but if you pick an arbitrary length and choose varchar(20) for a surname field you're risking production errors in the future when Hubert Blaine Wolfeschlegelsteinhausenbergerdorff signs up for your service. :D [https://en.wikipedia.org/wiki/Hubert_Blaine_Wolfeschlegelsteinhausenbergerdorff_Sr.]
印证了页面中'不要用表继承'的建议，作者亲身踩坑。
有趣的是，上周 HN 上有篇文章把表继承列为值得尝试的冷门 Postgres 特性。如果我先读了这篇，就不会浪费一个周六亲自搞明白为什么不该用它。
typenil查看英文原文
Funny how an article popped up on HN last week that mentioned table inheritance in a list of obscure Postgres features you should try out. If I'd read this first, I wouldn't have wasted Saturday finding out for myself why you shouldn't use it.
对 CURRENT_TIME 的存在意义提出疑问，并赞赏这种反例式教学。
'不要使用 CURRENT_TIME，永远不要。'——认真的问题：既然永远不该用，为什么还要提供这个选项？是向后兼容问题吗？顺便说这个列表很棒，'为什么不该做某事'是学习的好方式。
codegeek查看英文原文
"Don't use CURRENT_TIME. Never" Honest question. If we should never use it, why have it in the first place as an option ? Is it some type of backward compatibility issue ? This list is great btw. Why we shouldn't do something is a great way to learn stuff.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选