About putting back Firebird experimental

[Terrence Enger]

On Wed, 2019-09-04 at 16:59 +0200, Alexander Thurgood wrote:
> 
> I feel we would do well to remember
that this is people's live and
> valuable data we are potentially messing with here, and not all of
these
> users are DBAs, in fact rather the contrary. It matters not a jot that
> db engine XYZ can
outperform db engine ABC under circumstance PQR if the
> data that the user originally had gets
screwed up, or if the yearbook,
> contacts with photos, or multilingual accounts DB they were running
no
> longer functions correctly, or at all, they won't forgive us for it.

Indeed, I shudder to think what a customer of mine would have done if
I had given them a database conversion with the problems seen in the
conversion we are offering.

(To be fair, my commercial work was easier: I was always converting
one particular database.  And knowledge of the business process and
the customer's goal usually combined to make it pretty obvious how to
handle an infelicity which in the general case would be a problem
without a good solution.)

Still, as always, we can only do what we can do.  The most important
thing we can do is to not surprise the user.  I think we should try
very hard to avoid this grave sin.

To that end, I propose a pre-conversion report showing the problems
which will arise in the conversion of a particular database.  In the
case of a declared-too-long VARCHAR column, the report would show the
afflicted table and column name.  For each such column it would also
show the key values of--let us say--up to three rows where the value
actually stored is too long for Firebird.  And so forth.

I make this proposal diffidently, as it involves more work than I can
do.  I invite your thoughts.

Terry.