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: | Raw Message | Whole Thread | 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 |