Firebird does not correctly map some data types

[Former user]

This is because there are two different "slangs" ("dialects" in FB parlance) that support slightly different data types sets.

The attached patch is a preliminary attempt to introduce the concept: it has a particular weak point, but on the whole it makes the engine pass several tests.

The weak point is in FBDialect.type_descriptor(): it uses the dialect passed in the connection URL, instead of the actual dialect of the "current" connection; I'm not sure how it could access that information (the actual dialect is mandated by the database, not by the URL)

[Former user]

Support for FB dialect 1 and 3

[Former user]

Revised firebird backend

[Former user]

Here is a current snapshot of my version of the Firebird backend. Beyond stylistic touches, it better handle the various types, and fixes several other little glitches with the unit tests.

I do not think this is ready for inclusion in the trunk yet, I'd like to hear some other FB user feedback before. But I keep improving it.

[Mike Bayer]

i seem to recall someone had a problem with this patch so placing on hold until that gets figured out (like, was that resolved, etc).

[Former user]

I added a patch that uses a different approach to map FB types to SA ones:

Thu Dec  6 16:17:33 CET 2007  [e-mail]
  * [Firebird](Firebird) Better reflection of columns type
  Instead of relaying on the internal numeric code, lookup the
  associated real name. This has the extra benefit of correctly handling
  of DOMAINs

[Former user]

New approach at type reflection, with test, 2nd try

[Mike Bayer]

the most recent patch looks great, feel free to commit (and add a note to CHANGES).

[Lele Gaifax]

Committed as 3903. Dunno if I should close this bug: as said on IRC, handling different FB dialects would require a refactor and a split of the backend, as currently a single SA dialect cannot differentiate it's behaviour an a per-connection basis.

[Lele Gaifax]

I'm postponing the solution for this ticket. Maybe #526 will bring some new idea, or a new approach that does not need a split will appear...

[Mike Bayer]

we have the ability to use different type mappings per dialect (i.e. per connection backend) now, though this ticket is so old that I'm not even aware of status anymore on it with regards to our modern system, and we've had no subsequent requests/activity/etc.