I'm not certain this is the right solution. It's necessary for our postgres (actually enterprisedb) configuration, but we may be unusual. Without this fix, when I test against our db instance, I see 18 failing specs, for example:
3) DataObjects::Postgres with Array it should behave like supporting Array passing an Array as a parameter in execute_reader should return correct number of rows
Failure/Error: while(@reader.next!) do
DataObjects::DataError:
Couldn't parse date: 14-FEB-08 00:00:00
Even with this fix, there are still 4 failing specs in our configuration (all of which failed without the fix also; the first two don't appear to be date-related):
1) DataObjects::Postgres::Connection it should behave like a Connection with authentication support with an invalid URI should raise an error with a meaningless URI
Failure/Error: connecting_with("#{@driver}://peekaboo$2!@#4543").should raise_error(Addressable::URI::InvalidURIError)
expected Addressable::URI::InvalidURIError, got #<DataObjects::ConnectionError: fe_sendauth: no password supplied
2) DataObjects::Postgres::Connection it should behave like a Connection allowing default database with a URI without a database should connect properly
Failure/Error: conn = DataObjects::Connection.new("#{@driver}://#{@user}:#{@password}@#{@host}:#{@port}")
DataObjects::ConnectionError:
FATAL: database "apsmith_test" does not exist
3) DataObjects::Postgres with Date it should behave like supporting Date autocasting reading a Date with automatic typecasting should return the correct result
Failure/Error: @values.first.should == Date.civil(2008, 2, 14)
expected: #<Date: 2008-02-14 ((2454511j,0s,0n),+0s,2299161j)>
got: #<DateTime: 2008-02-14T00:00:00-05:00 ((2454511j,18000s,0n),-18000s,2299161j)> (using ==)
4) DataObjects::Postgres with Date exotic dates should return the number of created rows
Failure/Error: @values.first.should == Date.civil(1, 1, 1)
expected: #<Date: 0001-01-01 ((1721424j,0s,0n),+0s,2299161j)>
got: #<DateTime: 0001-01-01T00:00:00-05:00 ((1721424j,18000s,0n),-18000s,2299161j)> (using ==)
Second attempt at this pull request...
I'm not certain this is the right solution. It's necessary for our postgres (actually enterprisedb) configuration, but we may be unusual. Without this fix, when I test against our db instance, I see 18 failing specs, for example:
Even with this fix, there are still 4 failing specs in our configuration (all of which failed without the fix also; the first two don't appear to be date-related):