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: | 2006-02-26 14:40:33 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA0F7E9@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-02-26 14:58:29 | Re: possible design bug with PQescapeString() |
Previous Message | Tatsuo Ishii | 2006-02-26 14:40:13 | Re: possible design bug with PQescapeString() |