> At 8:24 PM +0000 7/21/05, Terrence Brannon wrote (on poop-group): >>> At 7:05 AM -0400 7/19/05, John Siracusa wrote: >>>> I use a module (Rose::DB) that parses and formats db-specific column values >>>> for me: various kinds of dates, "SET"s, arrays, all the crazy db-specific >>>> data types that are a pain to manually parse and then format. >> >> Are sets and arrays useful types? I don't think so.
You're looking at it the wrong way: are SETs and arrays used in real database installations running real apps? Yes, they are. Maybe they "shouldn't be" or whatever, but I need code that helps me deal with my reality, not the world as I might imagine it, were I consulted from day one ;) >> The date functionality you speak of might belong in DBI proper perhaps? I argued for that a while ago but it was deemed inappropriate for something as low-level as DBI. I can see some truth to that argument, but I'd still like to see some sort of official hooks in DBI, if not actual implementations. Anyway, even ignoring dates, the bottom line is that every database has its own funky data types, and syntaxes to go with them. I don't want to have to remember the N ways to write a BIT constant in Postgres, and I certainly don't want to have to parse them manually each time I want to do something with such a column value. I want my DB abstraction layer to help me here. If it's not DBI proper, then it should be something above it. -John
