LangRef 2.5beta1 - a few suggestions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

LangRef 2.5beta1 - a few suggestions

Aage Johansen
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.13        Integer 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.17        Data 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.22        Table 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.30        Table 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.31        Shorthand Casts for Date and Time Data Types
TIMESTAMP has been split over two lines as TIMES-TAMP.


P.32        Implicit 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&iu=/4140
_______________________________________________
Firebird-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-docs
Reply | Threaded
Open this post in threaded view
|

Re: LangRef 2.5beta1 - a few suggestions

Mark Rotteveel-2
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.13        Integer 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.17        Data 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.30        Table 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.31        Shorthand 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.32        Implicit 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&iu=/4140
_______________________________________________
Firebird-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-docs