On Sun, Oct 20, 2013 at 4:24 PM, Tom Lane <tgl@sss.pgh.pa.us> 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