On Mon, 8 Jun 2015 01:44:08 +0200 Joerg Sonnenberger <jo...@britannica.bec.de> wrote:
JS> > JS> Python's DB API v2 solved this problem by requiring Binary() wrappers. I JS> > JS> think this would be appropiate as well here and slight careful coding JS> > JS> would mean no overhead in terms of copying for C++11. JS> > JS> > I have the impression that you're speaking of function wrappers and not JS> > object wrappers, as I do above, but please correct me if I'm wrong and JS> > we're actually in a violent agreement here. JS> JS> No, object wrappers. The Binary() wrapping is essentially type sugar so JS> that the argument type matching can distinguish textish escaping from JS> binary escaping as needed. For the C++ use, the class would have to JS> support construction with a reference or rvalue and know whether it has JS> to free the data. This is to allow both use with literal values and JS> copy-free references to external storage. OK, so we're indeed speaking of the same thing then. JS> > JS> Downside is that the way prepared statements are handled for PostgreSQL JS> > JS> doesn't work this way. At the time of prepare, the types of the JS> > JS> arguments are not yet known. Comments and ideas? JS> > JS> > The only solutions I see are to either query the database for the column JS> > type (which introduces some overhead, i.e. at least another round trip JS> > which is not insignificant when using a remote database) or to delay JS> > preparing the statement until the arguments are known (which breaks the JS> > spirit if not the letter of SOCI API). JS> > JS> > However I think that using a binary_string class would avoid this problem, JS> > which seems like another good reason to do it like this. JS> JS> The binary_string class doesn't solve the problem. At the time prepare() JS> is called, no arguments are bound yet. Sorry, I guess I just don't really understand the problem then. What needs to be done differently in prepare()? Is it wrong to use PQprepate() with bytea? As we don't currently pass any parameter types to it currently, it seems like it ought to just do the right thing for us, what am I missing? JS> Querying the database for column types doesn't work either, since at JS> least PostgreSQL supports polymorphic functions as well. Again, I have a feeling that I'm missing something here. If we query the information schema for the column type we should get its real type back, shouldn't we? What do the polymorphic functions have to do with this? JS> Delaying the preparation breaks one of the existing test cases, but JS> seems reasonable stable as long as types are consistent across JS> executions. I think that's a reasonable demand on the interface. I don't see anything that would be broken for this, but errors wouldn't be reported in the same way and it introduces a difference between PostgreSQL behaviour and that of all the other backends. So while certainly not fatal it would still be nice if we could find some way of not doing this. Regards, VZ
pgpUrKvXu_cj_.pgp
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ soci-devel mailing list soci-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-devel
