Re: Remove implicit unique index creation on SERIAL columns?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Rod Taylor <rbt(at)zort(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove implicit unique index creation on SERIAL columns?
Date: 2002-08-20 01:34:10
Message-ID: 200208200134.g7K1YAo15826@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway wrote:
> Tom Lane wrote:
> > Joe Conway <mail(at)joeconway(dot)com> writes:
> >>I agree 100%. If you want an index, unique constraint, or primary key on
> >>a SERIAL, I think you should explicitly add it. SERIAL should give me a
> >>column that automatically increments -- no more, no less.
> >
> > Hmm, do you also want to eliminate the implicit NOT NULL constraint?
> >
> > I think that efficiency and orthogonality are adequate reasons for
> > dissociating UNIQUE from SERIAL. The efficiency argument is pretty
> > weak in the case of the NOT NULL part, though, so maybe backwards
> > compatibility should win out there.
>
> To be honest I wasn't thinking about NOT NULL. I'd agree with leaving
> that in place.
>
> Maybe I should restate my comment above: SERIAL should give me a column
> that automatically increments -- no more, no less -- and it should not
> allow me to override the value that it gives. Hence an implicit NOT
> NULL, but also an implicit rejection of a manual insert/update of that
> field (how hard would this be to do?).

If don't understand. We already have a unique index on the SERIAL
column, so why bother rejecting an insert/update that supplies the
value? We need the column to be unique, and that is forced, but why
prevent _any_ unique value from being used.

Clearly NULL is not a valid value and should be prevented with NOT NULL.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-08-20 01:36:16 Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Previous Message Bruce Momjian 2002-08-20 01:30:13 Re: Removing Libraries (Was: Re: Open 7.3 issues)