Re: possible design bug with PQescapeString()
- From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
- To: mha(at)sollentuna(dot)net
- Cc: 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 23:40:13 +0900 (JST)
- Message-id: <20060226(dot)234013(dot)82097837(dot)t-ishii(at)sraoss(dot)co(dot)jp>
> > > > > 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.
Thanks. Could you tell me what the number column in the file is? Can I
assign arbitary number for the function? (maybe next to the last
number?) I'm not familiar with win32 build.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Home |
Main Index |
Thread Index