On Sun, Jun 12, 2005 at 10:56:22PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
