Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] create database doesn't work well in MULTIBYTE mode |
Дата | |
Msg-id | Pine.GSO.4.02A.10002181535130.4777-100000@Krokodil.DoCS.UU.SE обсуждение исходный текст |
Ответ на | Re: [HACKERS] create database doesn't work well in MULTIBYTE mode (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
On Fri, 18 Feb 2000, Thomas Lockhart wrote: > ... > #ifdef MULTIBYTE > n->encoding = $6; > #else > n->encoding = 0; > #endif > ... > > where in fact if MULTIBYTE is not enabled and $6 is non-empty, the $6 > production never returns! It will if you write ENCODING = DEFAULT. Also, the rule you're looking at also covers the case CREATE DATABASE WITH LOCATION (no ENCODING clause given). In that case, with MULTIBYTE on, $6 will be set to GetTemplateEncoding() in the create_opt_encoding: /*EMPTY*/ rule. With MULTIBYTE off, you must set encoding to 0, because that's the default SQL_ASCII encoding, and the createdb() function (where this all ends up), does no further interpretation on the encoding at all. Either way you read it, I still think the previous code is completely correct as it stands. > 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?? Two reasons: First, it's better to have some rule than none at all, I thunk. Second, if someone mucks with the code and somehow we have a -1 encoding the database, we know exactly what went wrong. If you feel so inclined, you can change it to a zero, but after all the code works perfectly. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: