暂时没有这个计划，如果需要请自行 fork 修改，感谢反馈。

感谢 PR #33

@Chcp 我测试了一下 MySQL，有报错哦：

看来是因为用了 INT1 这个作为字段名了，MySQL 里是个保留字 😂 看来还是只能吧 ` 加回去，有啥建议不？

INT1是MySQL的数据类型吗？我查询了一下，好像没有这种数据类型。
PostgreSQL因为不支持``定义，所以我把它去掉了，在SQLite上测试通过的。但我确实没有在MySQL上测试过，因为平时不用。
如果仅仅是因为INT1命名导致的，如果以后计划pipe master版本支持PG，我建议是否可以改一个不跟MySQL数据类型冲突的名称？

INT1 是 MySQL 保留字。

改字段名已经来不及了……

Where 子句我正在用 GORM 的结构体支持重写，似乎奏效。

Good luck

改完后还需你那里帮忙测试下 PostgreSQL 是否兼容，谢谢。

好的，没问题。我会使用新的代码测试的。

我这里提交完了，麻烦在 postgres 分支上进行测试。

Hi @88250 ：
测试环境：本地代码编译执行，PostgreSQL版本为9.6。
由于对系统功能不慎了解，只能进行如下测试，应该有没有覆盖到的地方：
1、增加文章，修改文章，删除文章；
2、对文章进行评论，对评论进行回复，删除评论；
3、设置ShowSQL=true，未发现有SQL执行错误。

发现的缺陷如下：
1、[sessions] ERROR! securecookie: the value is not valid。这个错误貌似跟gorm无关。
2、增加一条评论，会出现多条记录；几率不少，有时出现两条记录，有时出现四条记录。
3、增加评论时，会跳到管理界面；

1. 这个不用管，是正常现象
2. 我这在 MySQL 上没重现，浏览器端 F12 看下请求发了几条，是不是发重了？后端好像没有做控制
3. 强制刷新页面再评论试试

又测试了下，在点击评论按钮是，都返回到了start页面，只能重新开始使用。形成循环了，无法进行评论。是与我本机环境有关？与SQL好像关系不大。

登录后在文章页面强制刷新一下再点评论按钮，有可能是缓存问题。

按照你的建议，在文章界面刷新界面，再执行评论，是在同一时间下发了多条创建评论的命令，随机的，1-n条都有可能，所以应该是前端的问题。

这个问题如果比较严重可以单独开 issue 我们再讨论看看 😅
PostgreSQL 没问题就行了，我关闭了，感谢帮忙，稍后我合并到主干。

@88250 请问一个问题，当初移植到PostgreSQL时，直接使用text字段来保存文章内容。虽然容量上绝对是够的（text支持1G长度），但如果频繁修改文章内容，查询和保存都是传输的整个文章内容吗？这样会不会影响性能？如果文章很长，分为多个章节和多个数据库字段来查询和保存是不是性能会更好？仅仅一个设计建议。

操作的是全文内容，文章最大长度应该校验过了，问题不大。