Postgres Pro
Downloads
Home   >   mailing lists

Thread: CURRENT_TIMESTAMP breaking with 7.1->7.2 dump/import

CURRENT_TIMESTAMP breaking with 7.1->7.2 dump/import

From
Mark Stosberg
Date:
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
defaultCURRENT_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

Re: CURRENT_TIMESTAMP breaking with 7.1->7.2 dump/import

From
Mark Stosberg
Date:
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/. . . . . . .

Re: CURRENT_TIMESTAMP breaking with 7.1->7.2 dump/import

From
"Christopher Kings-Lynne"
Date:
Sure you don't want 'now' instead of 'current'??

Chris


> -----Original Message-----
> From: pgsql-sql-owner@postgresql.org
> [mailto:pgsql-sql-owner@postgresql.org]On Behalf Of Mark Stosberg
> Sent: Wednesday, 20 February 2002 6:47 AM
> To: pgsql-sql@postgresql.org
> Subject: Re: [SQL] CURRENT_TIMESTAMP breaking with 7.1->7.2 dump/import
>
>
>
> 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/ . . . . . . .
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>