Changes between Version 6 and Version 7 of rfc28_sqlfunc


Ignore:
Timestamp:
Aug 5, 2010, 12:48:32 PM (14 years ago)
Author:
warmerdam
Comment:

finalize for proposal phase.

Legend:

Unmodified
Added
Removed
Modified
  • rfc28_sqlfunc

    v6 v7  
    33Author: Frank Warmerdam[[BR]]
    44Contact: warmerdam@pobox.com[[BR]]
    5 Status: Development
     5Status: Proposed
    66
    77== Summary ==
     
    1414SELECT (subtotal+salestax) as totalcost from invoice_info where 100 <= (subtotal+salestax)
    1515}}}
     16
     17A prototype implementation is now available for review in http://svn.osgeo.org/gdal/sandbox/warmerdam/gdal-rfc28
    1618
    1719== Technical Approach ==
     
    8688== Compatability Implications ==
    8789
    88 There are no anticipated backward compatability problems.  For the most part the change results in some OGR SQL statements to work that would previously have generated an error.
     90Some identifiers that were previously allowed as unquoted field names will likely now have to be quoted as they will be keywords in the grammar.  The keyword set is:
     91
     92* IN
     93* LIKE
     94* NULL
     95* IS
     96* SELECT
     97* LEFT
     98* JOIN
     99* WHERE
     100* ON
     101* ORDER
     102* BY
     103* FROM
     104* AS
     105* ASC
     106* DESC
     107* DISTINCT
     108* CAST
     109
     110The previous implementation was written in C and avoided all use of GDAL/OGR services so that it could be easily used in other contexts, including as the where clause evaluator of the OGDI library.  After this update the code is C++, and direct use of CPL error and other services has been directly incorporated.  This means the implementation used by GDAL and OGDI will diverge.
     111
     112For the most part the change results in some OGR SQL statements to work that would previously have generated an error.
    89113
    90114== Performance Implications ==
    91115
    92116I am hopeful that the evaluation speed will not be significantly different for simple selections, but each output field will need to be evaluated as an expression (with presumably one value-from-field node).
    93 
    94117
    95118== Implementation Plan ==
     
    99122== Testing ==
    100123
    101 All existing OGR SQL test suite tests should pass, and autotest/ogr/ogr_sql_test.py and perhaps other scripts will be extended for the new capabilities.
     124All existing OGR SQL test suite tests should pass.  A new autotest/ogr/ogr_sql_rfc28.py script will be introduced to test new functionality.
    102125
    103126== Documentation ==