[ic] PostgreSQL 7.0.x + IC 4.6.x: construct config error: ERROR: Bad timestamp external representation ''

[Mike Heins]

Quoting Dan (db@list.dnsalias.net):
> In recent versions of IC and PG, I have been having trouble getting even the
> 'construct' demo built.  During the start of the IC server, it goes through
> all the create table ... process, and often litters the following error
> several times:
> ds15 config error: ERROR:  Bad timestamp external representation ''
> And I get errors like: "We're sorry, the Interchange server is
> unavailable...
> We are out of service or may be experiencing high system demand, please try
> again soon." when trying to access cgi-bin/ds15/index.html, but sometimes it
> gives me "Undefined catalog: /cgi-bin/ds15".
> 
> What is really weird is that the databases seem to be created correctly.  I
> can browse them in psql and SELECT * them just fine.
> 
> I tracked down a few conversations of people who experienced the same error
> on the pgsql lists (of course not related to Interchanage).  Namely...
> http://www.postgresql.org/mhonarc/pgsql-bugs/2000-11/msg00088.html
> and
> http://www.postgresql.org/mhonarc/pgsql-bugs/2000-11/msg00096.html
> Basically I think it is because of some implicent TIMESTAMP --> DATE type
> conversion that we are doing, maybe during data import?

The key here is to set the time_field in userdb to "none". I thought
we handled that just fine in 4.6.0, and I did multiple PostgreSQL installs
myself on a blank db. But the fact is that the data constraints of 
PostGres make it very finicky for some things. Use DEFAULT properly
and you should be OK, but NOT NULL is very chancy with Postgres.

If your dbconf/* files are at all out of sync with your data files,
you will have problems with Postgres, that is for sure. The UserDB
directive can interfere with this, as can the update_date field in
some transaction tables. Those PostgreSQL timestamps are too hard for
me to figure out, that is for sure.

In 4.7.x, I have added a DEFAULT parameter much like COLUMN_DEF so
that we can handle SQLs that have less than ideal schemas for Interchange.
If they won't provide a default, we will. 8-)

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

Research is what I'm doing when I don't know what I'm doing.
-- Wernher Von Braun