Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
От | Tatsuo Ishii |
---|---|
Тема | Re: [HACKERS] libpq+MB/putenv(), getenv() clean up |
Дата | |
Msg-id | 20000113125212C.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] libpq+MB/putenv(), getenv() clean up (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> I think it is a very good idea to remove getenv() from PQmblen(). > getenv() is rather slow, at least on the machines I use, and having > to do it for each character processed is a huge performance hit. I didn't notice that. Thanks for the point. > PQmblen is exported by libpq (psql is an example of an application > that uses it). So very possibly, changing it would break a few client > applications. A possible answer is to leave PQmblen alone, and invent > a new routine with a different name that looks at PGconn. We could > deprecate PQmblen and delete it after a few releases. I'm not sure > if this is worth the trouble or not --- maybe it's OK to make a non- > compatible change to PQmblen. With the changes I propose, PQmblen() would not work anymore anyway. I'll post to interfaces list about the incompatible changes. > You would still do one getenv() during connection setup, right, to see > if PGCLIENTENCODING is set? Yes. >If you don't, that would be a significant > change in behavior that might make a lot of people unhappy. So the behavior won't be changed. -- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: