Re: possible design bug with PQescapeString()
От | Magnus Hagander |
---|---|
Тема | Re: possible design bug with PQescapeString() |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCEA0F7E9@algol.sollentuna.se обсуждение исходный текст |
Ответ на | possible design bug with PQescapeString() (Tatsuo Ishii <ishii@sraoss.co.jp>) |
Ответы |
Re: possible design bug with PQescapeString()
|
Список | 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
В списке pgsql-hackers по дате отправления: