[Kexi] pqxx and Kexi

[Adam Pigg]

On Thursday 15 October 2009 10:36:22 you wrote:
> Adam Pigg wrote:
> > Hi
> 
> Hi Adam!
> 
> > Im porting kexi to pqxx 3 from 2.6
> >
> > So far all ive ran into is the lack of pqxx::sqlesc.  I know this has
> > moved to the transaction and connection classes (why?) but in the kexi
> > class hierarchy, i need to escape a string in a class which doesnt have
> > access to a connection object?
> 
> This move was made necessary by a security fix in libpq itself.  As it
> turned out, its escaping function needs to know the encoding the string
> is in, because some multibyte encodings have characters that contain the
> byte that in ASCII or UTF-8 would have been e.g. a single quote.
> 
> So for example you might have a two-byte character consisting of some
> byte X and one that matches the ASCII character "'": X'
> 
> In that case, the naïve previous escaping function would just double
> that byte to "escape" it, producing X'' and voilà: a closing quote has
> been injected into a string--by the exact function that's supposed to
> prevent it.
> 
> I think your options are:
> 
> a) Write your own escaping function based on your own knowledge of the
> encoding that the code is going to run in.  I suppose Qt has some
> facility for breaking a string in the current locale's encoding down
> into unicode characters.
Jeroen,

Thanks for getting back, is it just the ' character which needs escaped by 
doubling it?

In which case, a QString::replace() could suffice, Jaroslaw, the main kexi dev 
can advise on that.
> 
> b) Give the class that needs this (temporary) access to a connection or
> transaction.
> 
The way i made it compile was to have a connection and transaction object, not 
actually connected to anything...i guess this is wrong as it isnt  possible to 
check the encoding without being connected.

Btw, i needed the transaction object as the connection versions of esc() arnt 
const, but transaction has both const and non const, you will know if this is 
intentional :)

Cheers

Adam
> c) Postpone the escaping to some point where the connection is available.
> 
> Not the best news, I know!  Wish we could have avoided this, but there
> you go.
> 
> 
> Jeroen
>