Re: [Firebird-docs] LangRef 2.5beta1 - a few suggestions /3
Hello Aage, Friday, April 1, 2016, 10:28:51 AM, you wrote: > p.97 > Table 5.8. ALTER TABLE Statement Parameters > The pagebreak reveal an akward split between the parameter > 'collation" and its description. > This may be a pdf artifact, but I'm using "Adobe Acrobat Reader DC, > 2015 Release | Version 2015.010.20660". No, it's not a "PDF artifact" but the way the formatter handles vertical alignment in table rows. That is, it's not your reader that has the problem, but the PDF itself. I've changed the VI for that row to "bottom". Let's see in the next build whether that improves anything. Thanks. Hope you're recovering well from whatever landed you in the Big House! Cheers, Helen -- ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] LangRef 2.5beta1 - a few suggestions /2
Aage Johansen wrote: > First, thanks to Paul for checking my suggestions. > Actually, I may have misremembered: I thought there might be pitfalls > regarding the sign of the result. There are. Or rather, there is one: 0x8000 - 0x map to negative INTEGER values, whereas 0x08000 - 0x0 map to positive BIGINTs. But I see Helen has taken care of that in her latest commit. > As for BETWEEN and the others: maybe precedence is totally irrelevant > for "comparison predicates". I just mentioned it since "comparison > operators" have defined precedence. According to IBPhoenix's Using Firebird and Helen's Firebird Book, BETWEEN...AND, LIKE, CONTAINING and STARTING [WITH] all have precedence 9 (lowest) among the comparison operators. I assume that the same is true for SIMILAR TO. > I've spent most of Easter in hospital, and haven't really been keen on > doing testing. Sorry about that. Hope you're doing alright now! Cheers, Paul Vinkenoog -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140 ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] LangRef 2.5beta1 - a few suggestions /2
Hi Helen, > Another thing we seem to have missed by the same method (!) was binary > strings in hex format. > > Unless you have feelings against it, I should just pick up the > relevant source from LangUpdate25, slot it into the appropriate > places and cross-ref where needed. Yes, please use whatever you can use. The hex numeral stuff is under langrefupd25-hexnumerals and (BIGINT-specific) langrefupd25-bigint; the 'binary' strings are at langrefupd25-hexbinstrings. Cheers, Paul -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] LangRef 2.5beta1 - a few suggestions /2
Hi Helen, > > p.51 (end of first paragraph): > > A CONTAINING search is not case-sensitive. > > > Maybe a comment/warning on accent-sensitivity? > > I think you might be the first person involved with this text who has > day-to-day experience with data in a language with accented > characters. What is there to say? Two short tests using iso8859_1 and utf8 reveal that CONTAINING is accent-sensitive, i.e. 'ABCDEFG' containing 'DÉF' is false, *unless* an accent-insensitive collation is used. I assume it's the same with other character sets. Cheers, Paul -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
[Firebird-docs] LangRef 2.5beta1 - a few suggestions /2b
A few more:
p.53 (top)
[ ] ( ) | ^ - + * % _ ? {
No "}" (terminating brace) ?
[:ALPHA:]: Latin letters a..z and A..z.
Should be: a..z and A..Z ?
p.57 Existential Predicates
... Existential predicates are so called because they use various
methods to test the existence of the value on the left side of the
predicate in the output results of subqueries on the right.
Using the first example:
SELECT *
FROM employee
WHERE EXISTS(SELECT *
FROM employee_project ep
WHERE ep.emp_no = employee.emp_no)
What is the "value on the left side of the predicate" and what is
"output result of subqueries on the right"?
It is not intuitive to me.
It seems to be better explained in the next paragraph, but the end is
not very clear:
... tests the fact of the existence of any number of matching rows
that is greater than none.
Would something like
... tests the existence of at least one matching row.
be simpler and clearer?
--
Aage J.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] LangRef 2.5beta1 - a few suggestions
On 2016-03-10 22:00, Aage Johansen wrote: > I may be way too late, or others may have noted > these already. This is a few suggestions that I collected in > February: > > == > Document version: 0.901 > > > > P.13Integer Data Types > BIGINT is defined as 64-bit integer, INTEGER is > defined as 4-byte integer. SMALLINT reveals > nothing about bits or bytes. Not very > consistent, but maybe this is all according to SQL rules? No, it is just inconsistency in the documentation. > The create table example for INTEGER contains > “CONSTRAINT INTEG_60” is this a good example? Not very, but also not very relevant. > > P.17Data Types for Dates and Times > There are examples of the extract function (p.18) > for TIME, but none for DATE. Extract functions > for DATE are only mentioned in passing under TIMESTAMP (p.18). That section could also use a link to the documentation of EXTRACT (both inline and at the end). > P.30Table 3.8. Literals with Predefined Values of Date and > Time > A small glitch with the lines in the lower right > of the table (or a pdf rendering problem?). Looks like the table has extra unused cells in its definition. > P.31Shorthand Casts for Date and Time Data Types > TIMESTAMP has been split over two lines as TIMES-TAMP. Not the case in the HTML version, seems to be a PDF rendering issue > > P.32Implicit Data Type Conversion > << > Implicit data conversion is not possible in > Dialect 3 the CAST function is almost always > required to avoid data type clashes. > In Dialect 1, in many expressions, one type is > implicitly cast to another without the need to > use the CAST function. For instance, the > following clause in a Dialect 1 SELECT statement is valid: > WHERE DOC_DATE < '31.08.2014' > and the string type will be cast to the date type implicitly. > >> > Valid in dialect 3 (as well as in dialect 1), I think. I know there are cases where string literals can be converted implicitly in dialect 3, but there are also cases where that doesn't work. It looks more like the cases where the implicit conversion works are bugs, strictly speaking. Mark -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140 ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
[Firebird-docs] LangRef 2.5beta1 - a few suggestions
I may be way too late, or others may have noted these already. This is a few suggestions that I collected in February: == Document version: 0.901 P.13Integer Data Types BIGINT is defined as 64-bit integer, INTEGER is defined as 4-byte integer. SMALLINT reveals nothing about bits or bytes. Not very consistent, but maybe this is all according to SQL rules? The create table example for INTEGER contains CONSTRAINT INTEG_60 is this a good example? P.17Data Types for Dates and Times There are examples of the extract function (p.18) for TIME, but none for DATE. Extract functions for DATE are only mentioned in passing under TIMESTAMP (p.18). P.22Table 3.5. Maximum Index Lengths by Page Size and Character Size The text above the column header Maximum length of an indexed string for a character set, bytes/character should just be Bytes/character (for the numbers 1 thru 6 in the column sub-headers). P.30Table 3.8. Literals with Predefined Values of Date and Time A small glitch with the lines in the lower right of the table (or a pdf rendering problem?). P.31Shorthand Casts for Date and Time Data Types TIMESTAMP has been split over two lines as TIMES-TAMP. P.32Implicit Data Type Conversion << Implicit data conversion is not possible in Dialect 3 the CAST function is almost always required to avoid data type clashes. In Dialect 1, in many expressions, one type is implicitly cast to another without the need to use the CAST function. For instance, the following clause in a Dialect 1 SELECT statement is valid: WHERE DOC_DATE < '31.08.2014' and the string type will be cast to the date type implicitly. >> Valid in dialect 3 (as well as in dialect 1), I think. == I had a few more, but realized they were the product of my confusion :-/ -- Aage J. -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140 ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
