Re: In RULEs, INSERT does not use DEFAULTs

From: Rod Taylor <pg(at)rbt(dot)ca>
To: David Fetter <david(at)fetter(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: In RULEs, INSERT does not use DEFAULTs
Date: 2005-06-13 04:03:21
Message-ID: 1118635401.723.33.camel@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2005-06-12 at 20:33 -0700, David Fetter wrote:
> On Sun, Jun 12, 2005 at 10:56:22PM -0400, Tom Lane wrote:
> > David Fetter <david(at)fetter(dot)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.

Change the table and view to use a domain.

CREATE DOMAIN tabviewtype_x AS integer DEFAULT 12;

Altering the default of the domain will bump both the table and view
defaults, or anywhere else that type happens to be used.

--
Rod Taylor <pg(at)rbt(dot)ca>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2005-06-13 05:13:02 Re: In RULEs, INSERT does not use DEFAULTs
Previous Message Tom Lane 2005-06-13 03:48:29 Re: In RULEs, INSERT does not use DEFAULTs