(oops, forgot to send the message quoted below to the list)
After looking into the time/interval errors a bit more, it looks like at least part of the problem with intervals is that the format of intervals changed with postgres 8.1 (adding the day field between ms and month), so I think I will just upgrade postgres rather than worry about any other hidden incompatibilities.
-- Bart
On 3/5/07, Bart Botta 00003b@gmail.com wrote:
The new version fixes the problem. I checked the tests, and they fail the same way with version 0.23.
WARNING: Postgres warning: CREATE TABLE / PRIMARY KEY will create implicit index "test_data_pkey" for table "test_data" WARNING: Postgres warning: CREATE TABLE / UNIQUE will create implicit index "test_data_c_key" for table "test_data" ... Did 26 checks. Pass: 22 (84%) Skip: 0 ( 0%) Fail: 4 (15%)
Failure Details:
TABLE []: Unexpected Error: #<CL-POSTGRES::PROTOCOL-ERROR {C7477A9}> Postgresql protocol error: Unexpected message received: 1..
TABLE []: Unexpected Error: #<SIMPLE-ERROR {C749909}>
#<SB-SYS:FD-STREAM for "a constant string" {C73C7B9}> is closed...
Version 0.23 and the new version also fail the time-types test,
TIME-TYPES []: (ENCODE-TIMESTAMP 2040 3 19 12 15 0 2) evaluated to #<TIMESTAMP 19-03-2040T12:15:00,002>, which is not TIME= to #<TIMESTAMP 01-01-2000T00:00:00>..
TIME-TYPES []: Unexpected Error: #<CL-POSTGRES::PROTOCOL-ERROR {C5FE3F9}> Postgresql protocol error: Unexpected message received: ^K..
The cl-postgres tests lock up in the date-query test, (postmodern:query "select '2 years -4 days'::interval") by itself causes
arithmetic error FLOATING-POINT-OVERFLOW signalled [Condition of type FLOATING-POINT-OVERFLOW]
Backtrace: ... 7: (SB-KERNEL:TWO-ARG-* 0.0d0 1000) 8: (CL-POSTGRES::INTERPRET-MILLISECS 18446743728109551616)
-- Bart
On 3/6/07, Bart Botta 00003b@gmail.com wrote:
After looking into the time/interval errors a bit more, it looks like at least part of the problem with intervals is that the format of intervals changed with postgres 8.1 (adding the day field between ms and month), so I think I will just upgrade postgres rather than worry about any other hidden incompatibilities.
That's good to know -- I'll add something about that to the compatibility info. Did you find out in which version exactly this change was introduced?
Marijn
On 3/7/07, Marijn Haverbeke marijnh@gmail.com wrote:
That's good to know -- I'll add something about that to the compatibility info. Did you find out in which version exactly this change was introduced?
Marijn
Looks like it was 8.1.0.
from the 8.1 release notes at http://www.postgresql.org/docs/8.1/interactive/release-8-1.html#AEN73858
Add a separate day field to type interval so a one day interval can be distinguished from a 24 hour interval (Michael Glaesemann)
Days that contain a daylight saving time adjustment are not 24 hours long, but typically 23 or 25 hours. This change creates a conceptual distinction between intervals of "so many days" and intervals of "so many hours". Adding 1 day to a timestamp now gives the same local time on the next day even if a daylight saving time adjustment occurs between, whereas adding 24 hours will give a different local time when this happens. For example, under US DST rules:
'2005-04-03 00:00:00-05' + '1 day' = '2005-04-04 00:00:00-04' '2005-04-03 00:00:00-05' + '24 hours' = '2005-04-04 01:00:00-04'
-- Bart
postmodern-devel@common-lisp.net