Centuries ago, Nostradamus foresaw when Kenneth Downs <firstinit.lastname@lastnameplusfam.net> would write:

Actually, I have seen a bit of "movement" recently.

What I have is _highly_ specific to PostgreSQL, but I'll bet the
approach could be used more widely:

Here's a stored procedure that checks to see if a particular table,
"sl_node", has been modified to include the new field, "no_spool", and
adds it, if necessary:

create or replace function @NAMESPACE@.upgrade_sl_node () returns bool
as '
DECLARE
       v_row  record;
BEGIN
  select 1 into v_row
    from pg_namespace n, pg_class c, pg_attribute a
    where
       n.nspname = ''@NAMESPACE@'' and
       c.relnamespace = n.oid and
       c.relname = ''sl_node'' and
       a.attrelid = c.oid and
       a.attname = ''no_spool'';
  if not found then
       raise notice ''Upgrade sl_node - add field no_spool'';
       alter table @NAMESPACE@.sl_node
           add column no_spool boolean default ''f'';
       update @NAMESPACE@.sl_node set no_spool = ''f'';
       return ''t'';
  end if;
  return ''f'';
END;' language plpgsql;

I have already written a procedure that generalizes this a bit
further; you get to do column-by-column updates by something like the
following:

 select add_missing_column('schema1', 'table_x', 'field_1', 'integer');
 select add_missing_column('schema1', 'table_x', 'field_2', 'numeric(20,4)');
 select add_missing_column('schema1', 'table_x', 'field_3', 'character(4)');

If you started off with enough of the table to at least have the
primary key, you could write a query that would pull out all of the
necessary bits of metadata from a database, something like...

select nspname as schema, relname as table_name, attname as
 field_name, [something indicating type that I haven't thought thru yet]
into exportable_metadata
from [various tables]
where
 [joining needful bits]
 [restricting to interesting tables];

Export that table, and then run the query:

select add_missing_column(schema, table_name, field_name, field_type)
  from exportable_metadata;

It's not directly portable, but other databases that have the ANSI
standard information schema may be able to do analagous things.

I think it's a plenty useful approach.  It copes only with differences
from one version to another; still useful.

In my experience these do not scale at all, either in script count or
programmer count.  The problem is that you have one-time code running at
the highest privilege level making many many assumptions about the prior
state of its target.  If you start trying to pull features out of sequence
it becomes a nightmare.

In a high volume situation, assume each script has a 99% chance of success,
which is extremely optimistic.  Two scripts together have 99 x 99 = ~98%,
three have 99^3 = ~97 and so forth.  The more scripts the less chance that
it will work.

There is no way out either.  The fact that the scripts are running at the
highest privilege level makes all enforcement techniques useless, a
programmer under deadline pressure will put anything he thinks will work
into the script, and you do not want to be the person saying the product
should not ship because of his script.

                              ^^^^^^^^^^^^^^

The thing to do is diff two specs defined in tables.  Basically you want
stuff like the following pseudo-query:

SELECT * FROM Spec_Columns
 WHERE column_ID NOT IN
 (Select Column_id from CurrentState_Columns)

...the next step is to build DDL to alter tables and add those columns.

I've always built database builders of one kind or another, and one
particularly ambitious one diff'd all server-side elements, including null
rules, defaults, stored procedures, functions, triggers and other stuff.
That experience convinced me that deliverying code to the server via a diff
tool is a mis-match, all server-side code should be generated out of scalar
data.  This is the only way to prevent programmers from violating
conventions and best practices policies.

My current project is a purely data-driven database builder, if you are
interested in updates on that let me know.