Re: [HACKERS] UTF-8 support
От | Serguei Mokhov |
---|---|
Тема | Re: [HACKERS] UTF-8 support |
Дата | |
Msg-id | 00b701c144a5$c0e4d780$5dd9fea9@gunn обсуждение исходный текст |
Ответ на | UTF-8 support (Jean-Michel POURE <jm.poure@freesurf.fr>) |
Ответы |
Re: [HACKERS] UTF-8 support
|
Список | pgsql-odbc |
----- Original Message ----- From: Tatsuo Ishii <t-ishii@sra.co.jp> Sent: Sunday, September 23, 2001 10:47 PM > > My question is now how many BE's/FE's would you return encodings for? > > I don't quite understand your question. What I thought were something > like this: > > SELECT pg_available_encodings(); > pg_available_encodings > ---------------------- > SQL_ASCII > EUC_JP > EUC_CN > EUC_KR > EUC_TW > UNICODE > MULE_INTERNAL > LATIN1 > LATIN2 > LATIN3 > LATIN4 > LATIN5 > KOI8 > WIN > ALT > SJIS > BIG5 > WIN1250 Which ones belong to the backend and which ones to the frontend? Or even more: which ones belong to the backend, which ones to the frontend #1, which ones to the frontend #2, etc... For examle, I have two fronends: FE1: UNICODE, WIN1251 FE2: KOI8, UNICODE BE: UNICODE, LATIN1, ALT Which ones SELECT pg_available_encodings(); will show? The ones of the BE and the FE making the request? In case I need to communicate with BE using one common encoding between the two if it is available. > BTW, another question comes to my mind. Why don't we make available > this kind of information by ordinaly tables or views, rather than by > functions? It would be more flexible and easy to use. Sounds like a good idea, make another system table for encodings and NLS stuff... S.
В списке pgsql-odbc по дате отправления: