Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] create database doesn't work well in MULTIBYTE mode |
Дата | |
Msg-id | 38ACCF59.875C0222@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] create database doesn't work well in MULTIBYTE mode (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
|
Список | pgsql-hackers |
> > At the moment, if the code is compiled without MULTIBYTE enabled, it > > will silently ignore any "ENCODING=" clause in a CREATE DATABASE > > statement. > template1=# create database foo with encoding='LATIN1'; > ERROR: Multi-byte support is not enabled > I believe that you have missed that a fair amount of work is being done in > the create_opt_encoding rule. Take a look. Ah, thanks. I was misled (why try actually testing it? I was reading the source ;) by some crufty code above createdb_opt_encoding (some tabs removed for readability): ... #ifdef MULTIBYTEn->encoding = $6; #elsen->encoding = 0; #endif ... where in fact if MULTIBYTE is not enabled and $6 is non-empty, the $6 production never returns! I'm planning on fixing this up (yacc willing) to *not* do anything special when MULTIBYTE is on or off, but will instead embed all of this funny business down in createdb_opt_encoding with the other stuff already there. So, why does the createdb_opt_encoding ($6 above) bother trying to return "-1" when MULTIBYTE is disabled, when that -1 is ignored and replaced with a zero anyway? Is it acceptable to return -1, as the $6 production does, or should it really be returning the zero which is passed along?? - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: