4 ms·
You can derive the current state (in CREATE statements and such) as part of your pre-commit build process if you really want it, no? Or interrogate any active c
by shantly 7y ago
You can derive the current state (in CREATE statements and such) as part of your pre-commit build process if you really want it, no? Or interrogate any active copy of the DB to get it at any time.
- mjw1007 7y agoThat's a bit like retrieving source code by pretty-printing a minimised form. It's not terrible, but it's not going to be as pleasant as the original source. If you maintain your schema like source code, you can use comments, organise it into files in a way that makes sense to you, maybe do a bit of light templating, and so on.
- shantly 7y agoI find the format of code that comes from tools deriving CREATEs from live databases to be totally acceptable, usually. Then again I'm the kind of person who prefers team-wide auto-formatting and a strict style linter, so maybe that's just me. > If you maintain your schema like source code, you can use comments, organise it into files in a way that makes sense to you, maybe do a bit of light templating, and so on. As usual—for the comments part, at least—PostgreSQL has your back. https://www.postgresql.org/docs/9.1/sql-comment.html https://www.postgresql.org/docs/9.1/sql-comment.html
- mjw1007 7y agoI use SQL-level COMMENTs and comments in the schema source for different things. The former can be made visible to people using the database; the latter are for people maintaining the schema. In any case, I don't think I'd get on with an auto-formatter that thought « COMMENT ON TABLE foo IS » was a friendly comment-introducing string. « -- » takes up rather less space.