| From: | Dani Oderbolz <oderbolz(at)ecologic(dot)de> |
|---|---|
| To: | Randall Lucas <rlucas(at)tercent(dot)net> |
| Cc: | pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: Change the behaviour of the SERIAL "Type" |
| Date: | 2003-06-27 08:45:07 |
| Message-ID: | 3EFC0413.7090006@ecologic.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Randall Lucas wrote:
>
> Wow, I had never actually faced this problem (yet) but I spied it as a
> possible stumbling block for porting MySQL apps, for which the
> standard practice is inserting a NULL. As I have made a fairly
> thorough reading of the docs (but may have not cross-correlated every
> piece of data yet, obviously), I was surprised to find I hadn't
> figured this out myself. It /seems/ obvious in retrospect, but it
> really baked my noodle when I first looked at some ugly MySQL queries.
>
> Respectfully, then, I move that a sentence outlining this
> functionality be added to User Manual section 5.1.4, "The Serial
> Types." Furthermore, anyone who has written or is writing a MySQL
> porting guide should include this, if he hasn't.
Yea, fine, but I propose a different (deeper) approach.
Why does SERIAL only enforce a DEFAULT?
This is not an exact imitation of an autoincrement, as a DEFAULT can be
overwritten.
In my oppinion, SERIAL should implicitly create a Trigger on the table,
which then
handles this transparently.
Would that be difficult?
(I am already writing a Procedure which gets all the info needed out of
the Catalog,
but my problem is that I need some dynamic statements in there...)
Cheers, Dani
| From | Date | Subject | |
|---|---|---|---|
| Next Message | btober | 2003-06-27 10:25:42 | Re: Postgres - Delphi Application |
| Previous Message | Tomasz Myrta | 2003-06-27 07:06:05 | Re: Postgres - Delphi Application |