| From: | "Aaron J(dot) Seigo" <aaron(at)gtv(dot)ca> | 
|---|---|
| To: | Ed Loehr <ELOEHR(at)austin(dot)rr(dot)com> | 
| Cc: | pgsql-hackers(at)postgreSQL(dot)org | 
| Subject: | Re: [HACKERS] getting new serial value of serial insert | 
| Date: | 1999-11-03 23:15:15 | 
| Message-ID: | 9911031617350B.00702@stilborne | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
hi...
> 
> No, and I'm not sure it'd be good to couple the two operations syntactically
> even if one thought of a clever way to do it.  Serial-insert value retrieval is
> a very frequent lightweight operation that fits nicely within current INSERT
> syntax, and thus it seems intuitively "natural" to stretch INSERT semantics
> in this way.
put that way, i can see your point clearly and agree... =)
i think this would be a nice addition to pgsql... 
  
> In the trigger scenario you mention, I'd be slightly more inclined to say it
> crosses the fuzzy gray line into the area where a subsequent SELECT is in
> order, as opposed to modifying INSERT syntax/semantics to allow this
> SELECT functionality.  How's that for fuzzy logic?
*nods* this is where the RETURN clause we've been batting around comes in as a
more powerful and secure way of dealing with this... oh well, i was hoping that
perhaps the serial return concept could be applied here as well...
-- 
Aaron J. Seigo
Sys Admin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-11-03 23:41:43 | Re: [HACKERS] getting new serial value of serial insert | 
| Previous Message | Ed Loehr | 1999-11-03 20:19:28 | Re: [HACKERS] getting new serial value of serial insert |