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>
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 |