On Mon, Jun 08, 2015 at 02:09:05AM +0200, Vadim Zeitlin wrote:
> On Mon, 8 Jun 2015 01:44:08 +0200 Joerg Sonnenberger
> <jo...@britannica.bec.de> wrote:
> 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?
Without parameter type, literal string format is assumed. Consider:
create temp table test (a text, b bytea);
insert into test values ('\\x0030', '\\x0030');
insert into test values (E'\\x0030', E'\\x0030');
select * from test;
That's why the OID dance is needed in the patch. Suggestions for
avoiding it are welcome :)
> 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?
SELECT foo(:arg1, :arg2)
-- how do you know the type of arg1 and arg2?
> 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.
Agreed.
Joerg
------------------------------------------------------------------------------
_______________________________________________
soci-devel mailing list
soci-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-devel
