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
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.
Hmm, do
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 that automatically
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 eliminate
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 an
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 increments -- no
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 turned
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 insertions
go
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. Turning it off
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 make insertions
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 data, then re-created
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 data,
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 NOT
13 matches
Mail list logo
