[gdal-dev] determine default SQL dialect

[Michael Sumner]

very helpful, thank you very much.  Quite a bit more to it than I thought.

Best, Mike



On Tue, Aug 2, 2022 at 7:27 PM Rahkonen Jukka <
jukka.rahkonen at maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> About INDIRECT_SQLITE dialect, it is documented in
> https://gdal.org/user/sql_sqlite_dialect.html
>
> “If the datasource is SQLite database (GeoPackage, SpatiaLite) then SQLite
> dialect acts as native SQL dialect and Virtual Table Mechanism is not used.
> It is possible to force GDAL to use Virtual Tables even in this case by
> specifying “-dialect INDIRECT_SQLITE”. This should be used only when
> necessary, since going through the virtual table mechanism might affect
> performance.”
>
> There is also an usage example for one special use case.
>
>
>
> ES is documented in https://gdal.org/drivers/vector/elasticsearch.html.
>
> MONGO_DB is documented in https://gdal.org/drivers/vector/mongodbv3.html.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev <gdal-dev-bounces at lists.osgeo.org> *Puolesta *Michael
> Sumner
> *Lähetetty:* tiistai 2. elokuuta 2022 10.43
> *Vastaanottaja:* gdal-dev <gdal-dev at lists.osgeo.org>
> *Aihe:* [gdal-dev] determine default SQL dialect
>
>
>
> Is it possible to determine the default SQL dialect  that will be used in
> the C++ API?
>
>
>
> It seems like the logic to pivot on dialect choice is only available to
> drivers internally (they know if they have one), so a map of formats is
> enough - but I wonder if I'm missing an API hook.
>
>
>
> Also, there appears to be dialect values DEBUG, INDIRECT_SQLITE, MONGO_DB,
> and ES in use but I gather they are for internal use (and so properly don't
> appear in the documentation).
>
>
>
> Thanks very much, Mike
>
>
>
>
> --
>
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsumner at gmail.com
>


-- 
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220803/0c9642cd/attachment.htm>