On 5/28/08, Dennis Cote <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > It seems docs/compile.html is wrong.
>  >
>  > SQLITE_OMIT_DATETIME_FUNCS
>  > If this option is defined, SQLite's built-in date and time manipulation
>  > functions are omitted. Specifically, the SQL functions julianday(), date(),
>  > time(), datetime() and strftime() are not available. The default column
>  > values CURRENT_TIME, CURRENT_DATE and CURRENT_DATETIME are still available.
>  >
>  > So it should be CURRENT_TIMESTAMP instead of CURRENT_DATETIME.
>  >
>
>
> You should file a documentation bug report to get this corrected.
>
>  It is an unfortunate choice of names, for the very reason that caused
>  this error.
>

Yes indeed.


>  I would really like to see this changed. I my opinion there should be at
>  least four such default values. Three that return the date and/or time
>  strings used now, and a fourth that returns a floating point julianday
>  number that would be stored in the database directly.
>
>    Name                         Inserts
>    ===================================================
>    CURRENT_DATE                 string date
>    CURRENT_TIME                 string time
>    CURRENT_DATETIME             string date and time
>    CURRENT_TIMESTAMP            real julianday number
>
>  Another possibility would be to use the TIMESTAMP name for an integer
>  unix epoch timestamp, and JULIANDAY for the floating point julian day
>  number, giving five default value codes.
>
>    Name                         Inserts
>    ===================================================
>    CURRENT_DATE                 string date
>    CURRENT_TIME                 string time
>    CURRENT_DATETIME             string date and time
>    CURRENT_TIMESTAMP            integer unix timestamp
>    CURRENT_JULIANDAY            real julianday number
>
>  I realize this will break backwards compatibility but perhaps this could
>  be considered for the upcoming 3.6 series. This change would provide for
>  smaller database files, since the integer and real formats are normally
>  smaller than the string they encode, and faster default inserts, since
>  they don't require executing the time and date string formating code.


Lovely idea. All that remains is convincing DRH.

I would also like to see the datetime functions documentation moved
from the wiki to the main syntax pages... perhaps under expressions.
Being out there in the wiki makes it seem like an afterthought hack.




>
>
>  Dennis Cote
>
>
>  _______________________________________________
>  sqlite-users mailing list
>  sqlite-users@sqlite.org
>  http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
Puneet Kishor http://punkish.eidesis.org/
Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/
Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to