Frank,
Frank Warmerdam wrote:
On Fri, Aug 6, 2010 at 10:48 AM, Tamas Szekeres <[email protected]> wrote:
+1
I assume that this feature will be utilized in the OGR sql query processor
and not directly in the ogr2ogr application.
Tamas,
ogr2ogr has a -select switch to identify desired fields
to be copied to the output. I imagine ogr2ogr could
benefit from ignoring all the undesired attributes using
this new api.
Currently there is no logic in the OGR SQL engine to
ignore fields not needed in the result but I can see that
adding this would be desirable. It would require some
work to walk all the expression trees (for the WHERE
and each of the column expressions) to identify the
fields that are used in the primary and joined tables. I
would potentially be willing to implement this optimization.
Please correct me if I am wrong, but is not the OGR SQL engine correct at
present, ie conformant to the SQL standard, whilst this proposal would render
OGR SQL non-conformant?
For example,
SELECT * FROM tablename WHERE condition
is the most common case and is the form currently delivered by OGR;
however,
SELECT column2,column3,column7,columnn FROM tablename WHERE condition
must be the second most common. SQL provides for the specification of columns
to return (* / all or a list) but does not, so far as I am aware, provide a
construct by which one can specify columns to be omitted from the results
(which, I suppose, would equate to * EXCEPT FOR).
Surely the goal is compliance with the standards?
Best wishes,
Peter
Re: the TestCapability(), I'd like to see this added too.
I think this could be done without restarting the RFC
process.
Best regards,
--
--------------------------------------------------------------------------------
Peter J Halls, GIS Advisor, University of York
Telephone: 01904 433806 Fax: 01904 433740
Snail mail: IT Services, University of York, Heslington, York YO10 5DD
This message has the status of a private and personal communication
--------------------------------------------------------------------------------
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
