> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Sábado 9 de Junio de 2001 17:28
>
> At 05:14 PM 6/9/01 -0400, Claudio Valderrama C. wrote:
> >- The idea of morphing a table to create a new one is nice in
> theory. If it
> >works in NetfraS, good for it. However, at this time, in FB it's
> unfeasible
> >IMHO: the mosquito (pardon, the bird) has today enough trouble altering
> >metadata to introduce yet another headache.
> >
>
> Why is it infeasible?

Not possible at this time, if we want to have firebird 1 before next year. I
thought I wrote the problem above: altering metadata now is unreliable. I'm
sure there are many bug cases we don't find yet. Until now, as a result of
changing the db schema, I've seen varchars that are mangled, DYN unsupported
verb messages, crashes, dimensions that are left out of sync with the domain
that owns them, intermitent/random issues when switching to/from int64
types, dependencies that not always are cleared or set, etc., to name a few
I can remember. So, basing a morphing capability in underlying flawed logic
is not the goal I want to seek for firebird 1. Maybe for FB 2 when we
stabilize metadata alterations. If I have to choose between giving users of
FB1
- an engine without much interesting new capabilities (like this morphing)
but not buggier than before;
- an engine with lots of innovations but with a sudden and big increase of
revenues for database recovery experts;

then I go for option 1.

(I'm not looking for 3rd world wide flame war. I'm only giving my opinion
based on my own experience with metadata changes. Thanks for taking my
motives into consideration. I alter my dev or test dbs but I recreate
production dbs and copy data.)

C.