Jeremy, I just pulled Sequel 3.0 and noticed that there seems to be an issue with the type_literal handling of a text column.
For example FIREBIRD_DB.create_table! :test6 do primary_key :xid blob :val String :val2 varchar :val3, :size=>200 text :val4 end inside the firebird spec fails on the text column because it tries to create the table as CREATE TABLE TEST6 (XID integer PRIMARY KEY , VAL blob, VAL2 varchar(255), VAL3 varchar(200), VAL4 text) which fails on the text column because it needs to be BLOB SUBTYPE TEXT So that led me to type_literal_generic_string which apparantly is the new method of altering types (as I've noticed this is the same within PostgreSQL). The problem seems to be that the call flow starts with type_literal which then decides whether to fall into type_literal_generic or type_literal_specific. Since "text" is considered specific we never get to type_literal_generic_string via type_literal_generic and therefore "text" gets pulled through and thus fails. I think the PostgreSQL adapter has the same issue but text is a valid type for it and therefore it passes the spec. The adapter would seem to want to change it to a bytea column but I can't see how it would get there unless there is another layer within the PostgreSQL adapter that the Firebird adapter doesn't have. Any ideas on the best route to patch this up? I apologize for not having tested a release candidate prior to the 3.0 release. John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
