Re: [HACKERS] getting new serial value of serial insert
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] getting new serial value of serial insert |
Дата | |
Msg-id | m11jDPy-0003kLC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] getting new serial value of serial insert ("Aaron J. Seigo" <aaron@gtv.ca>) |
Список | 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? Don't forget about a BEFORE ROW trigger that decides to return a NULL tuple instead of a valid (maybe modified) tuple. Thus, it suppresses the entire INSERT, UPDATE or DELETE operation silently. You cannot access a plain value then without having a flag telling that there is a value at all. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: