#Database #Data #Sysadmin #Web #Postgres #SQL #tech Transactions
呃... 其实我也不熟悉你们 DBMS 理论那一套和实践那一套，不过我作为一个普通用户来看，不是特别理解这到底坑不坑（
当然我也不知道为什么一定要 Large Object 资源必须在一个 Transaction 里被释放，他们肯定有他们的一套理由，在搞清楚他们的核心理念之前我觉得我没有资本妄加评论
Large Object 这个大家开发过 DBMS 应用的肯定都知道，就是说一个大对象
Large Objects in PostgreSQL lets you store files/objects up to 4 TiB in size.
The main benefit of using Large Objects instead of a simple column is that the data can be read and written in chunks (e.g. as a stream), instead of having to load the entire column into memory.
它有没有对应的 SQL 去查询我不知道，但就我所知可以用 oid(ObjectID) 查询，我觉得嘛，这个 API 相当有用。因为不用再把数据分为普通数据（DBMS 可存）和文件了。这样的话系统管理、备份、统计、迁移的时候肯定也方便一点，不依赖于文件系统
如果是使用 native （libpq）的程序员我觉得肯定注意得到喽，因为文档上有嘛，至于别的语言做的绑定，封装的如上面所说也都应该有提到，不过教到大家 LO 的确是个不错的实践，或许，虽然这个概念还不如一些平等数据交换、分布式、WebSocket、推送系统火
See also: [PG LO Docs, Node PGLO Binding, Source Header]
呃... 其实我也不熟悉你们 DBMS 理论那一套和实践那一套，不过我作为一个普通用户来看，不是特别理解这到底坑不坑（
当然我也不知道为什么一定要 Large Object 资源必须在一个 Transaction 里被释放，他们肯定有他们的一套理由，在搞清楚他们的核心理念之前我觉得我没有资本妄加评论
Large Object 这个大家开发过 DBMS 应用的肯定都知道，就是说一个大对象
Large Objects in PostgreSQL lets you store files/objects up to 4 TiB in size.
The main benefit of using Large Objects instead of a simple column is that the data can be read and written in chunks (e.g. as a stream), instead of having to load the entire column into memory.
它有没有对应的 SQL 去查询我不知道，但就我所知可以用 oid(ObjectID) 查询，我觉得嘛，这个 API 相当有用。因为不用再把数据分为普通数据（DBMS 可存）和文件了。这样的话系统管理、备份、统计、迁移的时候肯定也方便一点，不依赖于文件系统
如果是使用 native （libpq）的程序员我觉得肯定注意得到喽，因为文档上有嘛，至于别的语言做的绑定，封装的如上面所说也都应该有提到，不过教到大家 LO 的确是个不错的实践，或许，虽然这个概念还不如一些平等数据交换、分布式、WebSocket、推送系统火
See also: [PG LO Docs, Node PGLO Binding, Source Header]
GitHub
bleupen/node-pg-large-object
Large object support for PostgreSQL clients using the node-postgres library. - bleupen/node-pg-large-object