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
