Roman Simakov wrote:

> Hello, All.
>
>> Regards,
>> Vlad
>>
>> PS RedSoft already have some extension for external files, iirc
>>
>>
> Yes. RedSoft implemented an "ADAPTER" for external tables. The syntax
> likes CREATE TABLE table [EXTERNAL [FILE] ‘<filespec>’] [ADAPTER
> ‘<adap_name>’] [<cols_def>].
> Inside there is an abstract class and each its child implements one
> adapter. Now we supports two formats: existing one with fixed record
> length and binary log of fbtrace for using it as exterlan data for
> analyzing.
> Transactions are not supported. I think it would be good to support CSV too.
> On the one hand in Firebird one can implement build-in ADAPTERS for a
> lot of external file formats. On the other hand Firebird must not be a
> ALL format DBMS. Certainly, external tables very useful in many practice
> cases. It enough to support some common build in adapters as practice
> nice gadget such as CSV, XML, DBF. The other external table formats must
> be supported via external engines or loadable plugins.
>
>

This is a good idea, but one that has proven difficult to pull off. For
an exhaustive catalog of what one can do wrong, look at MySQL.

The original designed was intended for extensions to plugins while
supporting RMS files on VMS. The nature of ISAM systems is that they
generally:

* Don't have metadata, so the engine metadata may have to be used
* Support some degree of optimized access through keys
* Are highly idiosyncratic.

The MySQL pluggable storage engine interface has proven itself to be in
the happy middle ground between unsuitable for simple file systems and
unsuitable for external database engines. The extensions to support
transactional access are particularly inept. The fundamental lesson to
be learned from the effort is that if you think a single object
interface is suitable, you have your head wedged. It's much more
complex than that. Presuming simplicity complicates both the server and
client ends.