On Sun, Oct 20, 2013 at 4:24 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > No, and it's very unlikely that there ever will be, because it's > completely against the system structure at a number of levels. However, > there's more than one way to skin this cat. Many people keep their DDL as > text in some external CMS, and just load it into the database again after > any change. If you write the view as "CREATE OR REPLACE VIEW ..." in your > DDL, this is easy, at least for cases where you're not changing the set of > columns provided by the view. All right, so I'm getting the picture. Postgres developers are keeping their code in larger scripts and committing them to databases as batches, rather than editing them in place. We had a pretty slick setup going with developers writing code against a live dev database, with system documentation pulled from the SQL object comments, and the ability to script the whole database to/from git when needed for source control purposes. In some raw form, the workflow here is more like: write a module in a script file that re-commits all its objects to the database, and then execute that whole batch when testing or deploying. Commit that script to git. If I want to keep my documentation scheme, I'll need to pull the comments out of that file. A harder sell to my developers, but not impossible. I noticed some objects (like views) are very picky about dependents. Do you drop all the module's objects at the beginning of the script, just in case there's a change in the number or types of columns? That seems tricky, especially considering there will be modules that depend on yours. You also mentioned an external CMS. Any suggestions? --Brian -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
