Hello Peter Is there any reason why you prohibit a different encodings per one database? Actually people expect from collate per column a possibility to store a two or more different encodings per one database. Without this possibility - only UTF8 is possible for practical work - and for other encodings only pairs (national locale + C). Yes - it is from my perspective (as Czech programmer) - very typical situation and request is mix latin2 and latin1. I can live with limit, but it is very hard limit and should be documented.
Regards Pavel 2010/9/15 Peter Eisentraut <pete...@gmx.net>: > Following up on my previous patch [0], here is a fairly complete > implementation of this feature. The general description and > implementation outline of the previous message still apply. This patch > contains documentation and regression tests, which can serve as further > explanations. > > As this patch touches pretty much everything in the system, there are > probably countless bugs and bogosities, some of which I have marked with > FIXME, TODO, etc. But all the functionality is basically there, so it's > time someone else gives this a serious examination. > > Note: As previously, regression tests only work with "make check > MULTIBYTE=UTF8" and the feature overall only works on Linux/glibc. > > [0] > http://archives.postgresql.org/message-id/1279045531.32647.14.ca...@vanquo.pezone.net > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
