Re: - Mailing list pgsql-hackers

Oliver Elphick <olly@lfix.co.uk> writes:
> ERROR:  Column "year" is of type integer but default expression is
> of type double precision
> You will need to rewrite or cast the expression
>> 
>> Hmm ... what was the original coding of the default?

>    year         INTEGER      DEFAULT date_part('year',CURRENT_TIMESTAMP)

Well, date_part has always yielded double, so what we are really looking
at here is a side-effect of the tightening of implicit casting in 7.3.
It wants you to cast down to integer explicitly.

There was some discussion of allowing "implicit explicit casting" of
INSERT and UPDATE values to the target column's datatype, ie, allow a
cast path to be used even if it is not marked as implicitly castable.
If we did that then it's be reasonable to do it for default values as
well, and that would allow this coding to keep working.  But we did not
have a consensus to do it AFAIR.

> 3.  A view was created before one of the tables to which it referred.
>> 
>> This has been a problem all along and will continue to be a problem
>> for awhile longer.  Sorry.

> Is it not enough to defer all views until the end?  Why would they be
> needed any sooner?

Well, one counterexample is where the view is being used as a substitute
for a standalone composite type: there might be a function somewhere
that uses the view's rowtype as an input or result datatype.  I recall
seeing exactly that coding technique in some of Joe Conway's contrib
stuff (though it's now been superseded by use of standalone types).
In any case, such a rule won't ensure getting cross-references between
views to work.

The only real solution to pg_dump's ordering woes is to examine the
database dependency graph and do a topological sort to determine a
safe dump order.  As of 7.3 we have the raw materials to do this (in
the form of the pg_depend system table), but making pg_dump actually
do it is a major rewrite that didn't get done, and IMHO shouldn't be
tackled during beta.  (I sure want to see it for 7.4 though.)

In the meantime, I think that we shouldn't mess with pg_dump's basically
OID-order-driven dump ordering.  It works in normal cases, and adding
arbitrary rules to it to fix one corner case is likely to accomplish
little except breaking other corner cases.
        regards, tom lane