From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-18 17:07:23 |
Message-ID: | 3D5FD44B.2030702@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> 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 takes an explict act of the dba (ALTER TABLE)
for a special circumstance such as importing data. In the normal case
while it's turned on, it is the developers who need and get the foot
teflon (INSERT/UPDATE).
> What I would do if I wanted such a guarantee is to make insertions
> go through a view rule that prevents the serial column from being
> supplied directly. That's a general technique that applies to more than
> just serial columns, and it is also easy to control who has privileges
> to bypass the view.
I thought about the view rule myself. Nice, but beyond the grasp of
inexperienced users, who I think SERIAL is target for.
> AFAICT this "IDENTITY" thingie is an extremely limited kluge.
It is extremely limited -- that's why sequences are so much better
(IMHO). But SERIAL is for those who want something simple to use, don't
want to think about the implementation details, and don't mind it being
limited. Otherwise why have it at all -- just make everyone use sequences.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 2002-08-18 17:10:12 | Re: Open 7.3 items |
Previous Message | Gavin Sherry | 2002-08-18 17:05:40 | Re: [PATCHES] Better handling of parse errors |