Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: possible design bug with PQescapeString()


  • From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
  • To: "Tatsuo Ishii" <ishii(at)sraoss(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>
  • Subject: Re: possible design bug with PQescapeString()
  • Date: Sun, 26 Feb 2006 15:40:33 +0100
  • Message-id: <6BCB9D8A16AC4241919521715F4D8BCEA0F7E9(at)algol(dot)sollentuna(dot)se>

> > > > But actually I'd argue that
> > > > letting the client programmer supply the encoding is still a 
> > > > pretty dangerous practice.  Your example demonstrates 
> that if the 
> > > > encoding PQescapeString is told is different from the 
> encoding the 
> > > > backend parser thinks is in use, problems result.  Perhaps we 
> > > > should pass the PGconn to new-PQescapeString and let it 
> dig the client encoding out of that.
> > > 
> > > Sound good to pass PGconn to new-PQescapeString. Here is the 
> > > proposed calling sequence for the new function:
> > > 
> > > size_t PQescapeStringWithConn (const PGconn *conn, char 
> *to, const 
> > > char *from, size_t length)
> > > 
> > > If this is ok, I will implement for 8.2.
> 
> Here is the promised patches for 8.2. If there's no 
> objection, I will commit tomorrow.

Just a reminder - to work on win32, the new function needs an entry in
exports.txt.

//Magnus



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group