3 ms·
Another thing to consider that I don't see covered often is the object relational nature of PostgreSQL. So often I will see PostgreSQL being used like any othe
by sbuttgereit 11y ago
Another thing to consider that I don't see covered often is the object relational nature of PostgreSQL. So often I will see PostgreSQL being used like any other RDBMS when there are some very powerful development and querying tools in the system that are uniquely PostgreSQL.
Things like being able to treat relations as types, compound types and the like. Naturally where and when these things are appropriate and when they are not would make for good subject matter not often times covered.
- egeozcan 11y agoWhat is "relations as types"? I googled to no avail.
- icebraining 11y agoRelations are tables, indexes, views, etc. When you create one, PG will also create a composite data type[1] that corresponds to one of its rows. And you can use those types in interesting ways - for example, you can have a column in a table that stores a complete composite value. [1] http://www.postgresql.org/docs/9.3/static/rowtypes.html http://www.postgresql.org/docs/9.3/static/rowtypes.html
- sbuttgereit 11y agoYes, this is exactly why I think a guide examining such a topic would be good. You get a doc page for it (see icebraining's comment), but that's about it. Performance gets covered often, thinking about how to get the most of PostgreSQL's type system doesn't. I don't really use this feature to drive structure (really at all), but do use it extensively when programming functions in PL/pgSQL. I also exploit this in queries sometimes as well. It's not a life changing feature to be sure, but it is relatively unique and can help solve problems that are more cumbersome to solve without the feature.