At 09:21 AM 7/18/00 +0200, Vince Duggan wrote:

>
>
>However, if the engine internals can easily be modified so that an
>INSERT statement can create a cursor, and return multiple rows, then it
>may be worthwhile. I suspect the single row option will be very useful,
>but the multiple row option may be less useful, and may not be worth the
>effort. Perhaps someone can think up a scenario where multiple return
>rows will be useful - given that you may not have any control over the
>order of returned rows, and so may have trouble matching returned rows
>with 'input' rows...
>

The engine proper has two BLR statements that do insertions:

blr_store <relation ref> <statement-1>
blr_store2 <relation ref> <statement-1> <statement-2>

where <relation ref> is one of:

blr_relation <relation name> <context variable>
blr_rid <relation id> <context variable>

and <statement-1> is a blr statement executed after the in-memory
record has been created but before it is stored and <statement-2>
is a blr statemented executed after the record has been stored.
Statement-1 is generally a block of assignments to the new
record image. Statement-2 is generally a blr_send statement
containing a block of assignments from the various record fields
to the message parameters.

The blr syntaxes for these guys are:

blr_assignment <target> <source>
blr_begin <blr statement> ... blr_end
blr_send <message number> <blr statement>

The mapping of SQL into BLR is done by DSQL which is logically
in the client but physically linked with the engine. Everything
associated with "insert returning" is in DSQL, not the engine.


Jim Starkey