Stephan Szabo wrote:
> > 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.
>
> One reaso
On Mon, 19 Aug 2002, Bruce Momjian wrote:
> Joe Conway wrote:
> > Tom Lane wrote:
> > > Joe Conway <[EMAIL PROTECTED]> 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
Joe Conway wrote:
> Tom Lane wrote:
> > Joe Conway <[EMAIL PROTECTED]> 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.
>
Since there didn't seem to be anyone objecting to the notion of
decoupling UNIQUE from SERIAL, I'm going to go ahead with
reviewing/applying Rod's recent patch that does that (and fixes pg_dump
to dump 7.3 serials correctly). We can continue to debate about
the merits of making additional changes
Rod Taylor wrote:
>>>In MSSQL this
>>>is gotten around by allowing the properties of the data type to be
>>>altered, e.g. in MSSQL you can turn the IDENTITY property on or off
>>
>>Rather pointless if it can be turned off, wouldn't you say?
>>
>>What I would do if I wanted such a guarantee is to
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>>In MSSQL this
>>is gotten around by allowing the properties of the data type to be
>>altered, e.g. in MSSQL you can turn the IDENTITY property on or off
>
> Rather pointless if it can be turned off, wouldn't you say?
Not really. Turnin
> > In MSSQL this
> > is gotten around by allowing the properties of the data type to be
> > altered, e.g. in MSSQL you can turn the IDENTITY property on or off
>
> Rather pointless if it can be turned off, wouldn't you say?
>
> What I would do if I wanted such a guarantee is to make insertion
Joe Conway <[EMAIL PROTECTED]> writes:
> I know this causes problems for dumped and reloaded data.
Yup.
> In MSSQL this
> is gotten around by allowing the properties of the data type to be
> altered, e.g. in MSSQL you can turn the IDENTITY property on or off
Rather pointless if it can be turn
On Sun, 2002-08-18 at 02:35, Joe Conway wrote:
> Tom Lane wrote:
> > Joe Conway <[EMAIL PROTECTED]> 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 incre
Hi
-*- Joe Conway <[EMAIL PROTECTED]> [ 2002-08-18 06:36 ]:
> 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
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> 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
Joe Conway <[EMAIL PROTECTED]> 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
Rod Taylor wrote:
> I'd like to propose dropping the auto-creation of UNIQUE indexes on
> serial columns for the following reasons:
>
> 1. Serials with indexes are quite difficult to handle in pg_dump. It
> means that the implicitly created unique index must be destroyed prior
> to loading the d
13 matches
Mail list logo
