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