Rob Browning wrote:
> 
> it's also possible
> that when we move to SQL, that we might drop the kvp_frames
> altogether.  That's something we'll have to discuss.  One of the
> reasons for implementing them was that it made adding new fields when
> we needed them much easier, but it's my impression that databases also
> have established ways for handling this kind of thing, so we may be
> able to just leverage those bits.  Hard to tell before we really
> consider the issues carefully...

Ayup - snipped from the postgresql manual:

  Name

     ALTER TABLE -- Modifies table properties
        
  Synopsis

  ALTER TABLE table
      [ * ] ADD [ COLUMN ] column type
  ALTER TABLE table
      [ * ] RENAME [ COLUMN ] column TO newcolumn

Also, speaking from experience, it's generally pretty trivial to save a
table, recreate it, and reload it from the save. E.g.:

  create table foo_save as select b, c from foo;
  drop table foo;
  create table foo (new_a char, changed_b int, c date);
  insert into foo values select 'filler', int (b), c from foo;

I do this a lot in the database projects I'm a dba for at work.

-- Pat


-- 
      This message does not represent the policies or positions
             of the Mayo Foundation or its subsidiaries.
  Patrick Spinler                       email:  [EMAIL PROTECTED]
  Mayo Foundation                       phone:  507/284-9485

_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Reply via email to