This turned out to have an easy work around:
perl -pi.bak -e "s/'current'/CURRENT_TIMESTAMP/" my_dump.dmp
-mark
Mark Stosberg wrote:
>
> Hello and thanks for the Postgres team for another fine release of
> Postgres. I'm working on doing some test dump/imports from Postgres 7.1
> to Postgres 7.2.
>
> I'm using a 7.1 pg_dumpall, and a 7.2 psql to import.
>
> It's hanging on this error:
> ##########################
> CREATE TABLE "mail_history" (
> "mail_id" integer DEFAULT
> nextval('mail_history_mail_id_seq'::text) NOT NULL,
> "subject" character varying(200),
> "body" text,
> "group_id" integer,
> "date_created" date DEFAULT date(('current'::"timestamp" +
> '00:00'::"interval")) NOT NULL,
> "n_sent" integer DEFAULT 0
> );
> ERROR: Bad timestamp external representation 'current'
> ##################
>
> The use of 'current' is clearly not suported as stated in the upgrade
> docs. What's frustrating is that the SQL I used to create the table WAS
> valid, using the standard CURRENT_DATE function, but Postgres internally
> connverted this into this broken format. Here was my original create statement:
> #########
> create table mail_history (
> mail_id serial,
> subject varchar(200),
> body text,
> group_id integer,
> date_created date not null default CURRENT_DATE,
> n_sent integer default 0
> );
> #######
>
> This is from an old project. It might have started in Postgres 6.5.x and
> then been imported into Postgres 7.0 and then Postgres 7.1. Is there a
> way that I help coax Postgres into providing better support for this
> kind of legacy data?
>
> -mark
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
-- . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer
mark@summersault.com Summersault, LLC 765-939-9301 ext 223 website development . . . . .
http://www.summersault.com/. . . . . . .
