Dave Page wrote:
> Oliver reported:
>
> 2. The dump produced:
> CREATE TABLE cust_alloc_history (
> ...
> "year" integer DEFAULT date_part('year'::text,
> ('now'::text)::timestamp(6) with time zone) NOT NULL,
> ...
> ERROR: Column "year" is of type integer but default expression is
> of type double precision
> You will need to rewrite or cast the expression
>
> For an original definition of:
>
> year INTEGER DEFAULT
> date_part('year',CURRENT_TIMESTAMP)
Wow. That is clear. Why are we returning "year" as a double? Yes, I
see now:
test=> \df date_part List of functions Result data type | Schema | Name |
Argumentdata types ------------------+------------+-----------+----------------------------------- double
precision| pg_catalog | date_part | text, abstime double precision | pg_catalog | date_part | text, date double
precision| pg_catalog | date_part | text, interval double precision | pg_catalog | date_part | text, reltime double
precision| pg_catalog | date_part | text, time with time zone double precision | pg_catalog | date_part | text, time
withouttime zone double precision | pg_catalog | date_part | text, timestamp with time zone double precision |
pg_catalog| date_part | text, timestamp without time zone
I would love to say that this is related to change in casts, but that
isn't the case. It is the new double-precision handling of dates; and
I see no easy way to fix this, and you can't fix this after the data
load because the table wasn't created. Yuck.
I have to ask, why are we using a double here rather than a 64-bit
value, if available?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
