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 sti
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 tic
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 PGEn
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 ot
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 thin
