|
Perhaps:
"because one or more trailing blank spaces at the end of a character string do not distinguish it from the same string without the trailing blanks". Does a wording like that make the meaning any clearer? Problem is that it is very difficult to translate this kind of vague expression ...
Sometimes translating them straightly results in unreadable expression in Japanese. It can be clearer when it is translated into Japanese ... "No value" may be recognized as "value which may be ignored" in English, I think .
But in sence of Japanese word usage, no value is just null. Then the sentence can be directly translated as "because a blank space is null" ... // This may be nonsence because this is English and not Japanese ... By the way, is the meaning of the sentence different ,
if it was replaced as "because a blank space is a special value" ? If so , I can translate the sentence as if it was replaced without replacing in English. Sorry for confusing discussion ... Would this be less ambiguous?
"...because a string that has one or more trailing blank spaces is treated as identical to the same string that does not have trailing blank spaces." I know it's a bit clumsy. But a phrase beginning with "without" can be either adverbial or adjectival, so it took me a while to figure out if the "without" in Bryan's suggestion appled to the noun "string" or to the verb phrase. I think that "because a blank space is a special value" doesn't really explain the situation. I think we are too thinking about *value* itself .....
How about "because they are of equal in comparison" ? how about:
"because trailing spaces are ignored for character comparisions" PS. Can long varchar be used in a MAX? I see.
I will translate Dan's phrase into Japanese. Attaching
Thanks Kim! The diff and HTML page look good to me.
As long as we're working on this page, does anybody know the answer to Dan's question about LONG VARCHAR? Is that datatype allowable for a MAX? OK, I tried it, and I think LONG VARCHAR is *not* supported for MAX:
ij> create table D2365 (a int, b varchar (20), c char(10), d long varchar); 0 rows inserted/updated/deleted ij> select max(a) from d2365; 1 ----------- NULL 1 row selected ij> select max(b) from d2365; 1 -------------------- NULL 1 row selected ij> select max(c) from d2365; 1 ---------- NULL 1 row selected ij> select max(d) from d2365; ERROR 42Y22: Aggregate MAX cannot operate on type LONG VARCHAR. Kim, what do you think about revising your patch to remove the reference to LONG VARCHAR as well? Yes, I'll be glad to remove the reference to LONG VARCHAR. Should I say explicitly that it is not supported?
I wonder if there are any other unsupported builtin data types? The topic says MAX works "on expressions that evaluate to built-in data types (including CHAR, VARCHAR, DATE, TIME, CHAR FOR BIT DATA, etc.)". Hm, I wonder if MIN needs to be fixed too?? Well, I guess that would be a separate issue. I think we should just remove the reference to LONG VARCHAR from that one paragraph.
MIN does indeed appear to have the same situation. ij> select min(d) from d2365; ERROR 42Y22: Aggregate MIN cannot operate on type LONG VARCHAR. I think we could go ahead and address that now, if you want. I don't know that a separate issue is necessary; the basic issue here involves the paragraph on trailing space handling and it's the same paragraph in both doc pages. Although, curiously, the page for MIN has slightly different text: " For CHAR, VARCHAR, and LONG VARCHAR, the number of blank spaces at the end of the value can affect the result." Do I rename this issue as "brushing up pages for MAX / MIN in Derby Reference Manual" ?
I found another problem in page for MIN.
There exists next sentence : The type's comparison rules determine the maximum value. Here, maximum should be minimum. I came to feel it would be good to cluster brushing up issue for those.
I will rename this issue. Bryan, thank you for those suggestions about the MAX and MIN pages, and Tomohito, thanks for renaming this issue -- that is the right thing to do.
Should I change the language in MIN about blank spaces to match the language in MAX? Reading page for MIN,
I feel that similar description for trailing blank spaces should be in the page for MIN as the page for MAX. // It may be verbose to have similar description in each pages , // but I think that verboseness is prefered in the reference manual. Attaching
MAX is an aggregate function that evaluates the maximum of the expression over a set of values ... MIN is an aggregate function that evaluates the minimum of an expression over a set of rows ... Which should it be, values or rows? They may both be correct, but we should pick one. (I'll change "the expression" to "an expression" for MAX, too. I just noticed that!) I think I figured it out -- I made the first sentence of MAX consistent with the first sentences of the other aggregate functions ("the maximum of an expression over a set of rows").
Sorry about the odd numbering: the final patch is I think there are no problem for this patch.
Sending src/ref/rrefsqlj27781.dita Sending src/ref/rrefsqlj33520.dita Transmitting file data .. Committed revision 514156. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Brushing up pages for MAX and MIN in Derby Reference Manual
"because a blank space is a special value"