On Sun, Jun 12, 2005 at 10:56:22PM -0400, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > At one time, INSERTing a NULL into a column with a DEFAULT used to
> > INSERT the DEFAULT. Is there some way to get this behavior back?
>
> PG has *never* done that in any version that I can recall, and it
> isn't likely that we would install such an obvious violation of the
> SQL spec.
> The correct way to get the behavior you are after is to attach a
> default to the view's column (ALTER view ALTER col SET DEFAULT ...)
With all due respect, that's a giant foot gun in terms of maintenance,
i.e. making a single behavior depend on two things that can easily
get out of sync. With hand-altered DEFAULTs, there's no way to alter
the DEFAULTs on the the base TABLE and have those changes propagate,
as people would usually want it to.
I can see how somebody might want a VIEW's column to have a DEFAULT
that was different from the column to which it refers in some specific
case. However, "defaults to different from the underlying column's
DEFAULT" is a Bad Thing(TM).
I believe this isn't just my problem. Without access to a the
underlying column's DEFAULT, how can people implement the automated
WRITEable VIEWs?
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!