Hi Øystein,
Øystein Grøvlen wrote:
> Peter Gulutzan wrote:
>> Hi Øystein,
>>
>> Øystein Grøvlen wrote:
>>> Bar,
>>>
>>> Forgot to mention two things:
>>>
>>> 1. Since I am not able to understand from the work log how things are
>>> supposed to work, I have given on verifying that your changes
>>> behaves
>>> correctly with respect default charset vs ASCII. (Since you did not
>>> write nor nor approved the worklog, that is not your fault.)
>> <cut>
>>
>> I wrote the worklog. Sergei Golubchik approved.
>> It says return "with character set = character_set_connection".
>> It says "this worklog has nothing to do with ascii".
>>
>> What is it that is our fault here?
>
> It may be that I have misunderstood something here. Could you please
> comment on the following excerpt from the review discussion between
> Bar and me:
>
> Øystein Grøvlen wrote:
> > Alexander Barkov wrote:
> > > Øystein Grøvlen wrote:
> > >> 1. I think I understood most of the worklog, but I am a bit puzzled
> > >> with the following statement: "Now this worklog has nothing
> to do
> > >> with ascii."
> > > >
> > >> Why then does this patch introduce methods called
> > >> val_ascii and change charsets from binary to latin1? Is this
> > >> related to what is said in the section "Other automatic
> > >> conversions"? I am not really able to tell what that section is
> > >> saying. I think the worklog needs to explain this better.
> > >
> > > Thanks for noticing this.
> > >
> > > This phrase needs to be either removed,
> > > or rephrased to something like this:
> > >
> > > "This patch does not introduce a build-in 'ascii' character set".
> > >
> >
> > OK. So this means that there are no 'ascii' character set, but latin1
> > is used instead?
> >
> > My problem is that I am not able to understand from the worklog where
> > ascii should be used instead of the character set/collation defined by
> > the connection. Is this so obvious that it does not need to be
> > mentioned, or is it mentioned in a way that I am not able to
> > understand?
> >
> ...
> > >> 6. It is probably not my business, since I am not the architectural
> > >> reviewer, but it would be easier to verify the behavior if
> the work
> > >> log had contained a table with all functions affected, what they
> > >> used to return, what they will return, and what charset will be
> > >> used. The way it is now, it is a bit hard to verify that all has
> > >> been covered, and, especially, what charset should be used.
> > >
> > > I proposed that to PeterG and Sergei, who are the author and
> > > architecture reviewer for WL#2649. Their verdict was "no needs",
> >
> > As I said, it would be nice to know when ascii is supposed to be used
> > or not.
> >
>
> --
> Øystein
The proposed wording change "does not introduce a built-in ascii
character set"
is pointless, because the MySQL ascii character set already exists.
The current wording "This worklog task has nothing to do with ascii" was
a necessary emphasis because originally the worklog task said ascii is a
requirement.
This was superseded by the connection-character-set requirement.
See dev-private email thread "BINARY and VARBINARY".
*https://intranet.mysql.com/secure/mailarchive/mail.php?folder=4&mail=25886
*I fail to see anything erroneous or ambiguous about "not ascii".
The suggestion that "latin1 is used instead" is incorrect. The
requirement is
that the user will see a result in the connection character set, which
does not
have to be latin1. And, of course, it does not have to be ascii.
Perhaps the confusion is caused by the use of names like 'val_ascii'.
Since digits and basic punctuation are all in the ascii repertoire, it's
of course
true that the result happens to be in ascii. It also happens to be in
latin2, or
any other 8-bit character set that MySQL supports. If somebody wants to
say "this value is ascii", that's fine, and trivial, and has nothing to
do with
the worklog task requirement.
I did not employ the words "no needs". What I said about WL#2649 is in the
dev-private email threads "*WL#2649 Number-to-string conversions"
and "A**RCH REVIEW REQUEST: WL#2649 Number-to-string conversions".
*Peter Gulutzan
Sun Microsystems / MySQL
