from my perspective my comments on the ticket still stand - the MySQL
specificness has to be removed and the interface regarding encoding
and such should be simplified.The MySQL import and __supported
business should be removed as well - I know the Interval type is doing
the same
Agreed - it makes more sense to have a generic enum type which may fall back
to software should the db not actually support it. Having said that, in
terms of using (selecting/updating) an enum field the syntax should be quite
similar across implementations. While I'm not familiar with databases
On May 27, 2009, at 12:09 PM, Dimmich Damian wrote:
Would it, based on the above assumption, not be possible to have a
generic enum type that figures out what to do based on what type of
database we are connected to without needing to specify MSEnum or
the currently ficticious PGEnum?
Great :). So, what needs doing to get Enum support? The ticket, which is
part of the 0.5.5 roadmap mentions adding tests, would having tests be
sufficient for getting it into 0.5.5?
Is it still worth writing a posgres/enum PGEnum type for 0.5.x and
integrating it with the patch that is in the
On May 27, 2009, at 12:39 PM, Dimmich Damian wrote:
Great :). So, what needs doing to get Enum support? The ticket,
which is part of the 0.5.5 roadmap mentions adding tests, would
having tests be sufficient for getting it into 0.5.5?
tests plus the cleanup discussed.
Is it still
