Message-ID: <3EFC0413.7090006@ecologic.de>
Date: Fri, 27 Jun 2003 10:45:07 +0200
From: Dani Oderbolz <oderbolz@ecologic.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.3.1) Gecko/20030425
MIME-Version: 1.0
To: Randall Lucas <rlucas@tercent.net>
Cc: pgsql-sql@postgresql.org
Subject: Re: Change the behaviour of the SERIAL "Type"
References: <FA785BC0-A7EF-11D7-8248-000A957653D6@tercent.net>
In-Reply-To: <FA785BC0-A7EF-11D7-8248-000A957653D6@tercent.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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