James Cloos wrote:
> While looking at how best to get back data from an insert, I see that in
> pgsql the recommended way is via INSERT ... RETURNING. Such as:
[snip]
> After which a db_get_result(0, 0) can be used instead of the current
> db_insert_result("message_idnr").
Is it worth the effort?
> So, I think db_insert_result() should be rewritten for pgsql to use
> db_get_result() and something should be added to enable adding the
> "RETURNING foo" string to the query when applicable.
>
> Unfortunately, according to their docs, neither sqlite nor mysql (even
> version 6) supports INSERT RETURNING. So this will require a new
> function in the dbfoosql modules which should take a char* (just like
> db_insert_result()) and return a char* to either and empty string for
> mysql and sqlite or "RETURNING %s" for pgsql.
?why not return a u64_t like we do now?
>
> Looking at how, eg, db_add_sievescript() works, I take it this new
> function should work something like dm_stresc() does and that the
> calling function would then be responsible to g_free() the returned
> char*, yes? Ie, use g_new0() to allocate the new string?
>
> Is there any special trick when allocating ""? Or should I use " "?
returning a g_new0(char,1) perhaps?
> Or, for that matter, is there any preference between using sprintf(3) vs
> some other method to append the argument char* to the char* "RETURNING "?
A similar pattern can be found in dm_db.c,date2char_str which uses an
allocated string, but later code as found in db_mailbox_has_message_id
uses char[] arrays.
>
> I beleive this will be a benefit even w/o the contig uids work.
>
> All thoughts on how best to implement this change are most welcome!
Well, consider sticking it it's own branch so we can do separate merges
of the changesets - insofar as it doesn't depend on the tuple code of
course. Other than that: use your own judgement.
But: move your developement to the HEAD of my git-tree. (You can now
pull using: git clone git://nfg3.nfgs.net/dbmail). There is no way the
tuple change is going into the 2.2 tree anyway.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
