On Mon, Jun 08, 2015 at 07:40:36PM +0200, Vadim Zeitlin wrote:
> On Mon, 8 Jun 2015 02:56:33 +0200 Joerg Sonnenberger
> <jo...@britannica.bec.de> wrote:
>
> JS> Without parameter type, literal string format is assumed. Consider:
> JS>
> JS> create temp table test (a text, b bytea);
> JS> insert into test values ('\\x0030', '\\x0030');
> JS> insert into test values (E'\\x0030', E'\\x0030');
> JS> select * from test;
>
> Sorry, but I'm even more lost now than before... For the record, the
> result of the above is:
>
> a | b
> ---------+----------------
> \\x0030 | \x5c7830303330
> \x0030 | \x0030
>
> but what do we want to have, the first value or the second one? It seems to
> me that the first one, being the binary representation of the string
> "\x0030" (6 bytes) is right here but I am not sure about this and I'm also
> confused by the double backslash: it's not supposed to be interpreted at
> all outside of E'...' strings, is it?
The second row is the expected result. The problem is that the text
format without OID tagging doesn't allow the necessary quoting of
embedded NULs. The double backslash is needed as there are two levels of
quoting here. For the purpose of the parameter value, \x0030 would be
correct.
> JS> That's why the OID dance is needed in the patch. Suggestions for
> JS> avoiding it are welcome :)
>
> What happens if we don't touch PQprepate() but pass the correct OIDs to
> PQexecParams(), could this work?
PQexecParams works, that's what the patch uses. But PQexecPrepared has
no OID parameter. It might be possible to just pretend polymorphism
doesn't exist and hope the automatic type machinery figures out byteas
correctly (and require the user to explicitly cast otherwise). But that
feels dirty too.
Joerg
------------------------------------------------------------------------------
_______________________________________________
soci-devel mailing list
soci-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-devel
