Hi David and colleagues, This whole topic of introducing QGIS expression support into provider side filtering is related to (or almost the same) as the SQL compiler that Matthias worked on: making sure that as much as possible, QGIS expressions are converted/translated into server/provider side SQL commands where possible (e.g. PostgreSQL, SQL Server, SqLite) or OGR filters (a limited subset of filters).
As an end user I would like to get a visual feedback whether the QGIS expression in the filter can be translated/run on provider side or if the data has to be loaded in full and needs to be filtered in QGIS as a client. Such a visual feedback would give the end user an idea of how efficiently the filtering can be expected. Just some thoughts around that. I am also interested in seeing a QEP on this topic. We discussed this very same issue a few years ago, and back them it was deemed to complicated / too much effort. But things have changed since then ... Greetings, Andreas On Thu, 25 Sept 2025 at 08:44, David Signer via QGIS-Developer < [email protected]> wrote: > Thanks for the feedback, everyone. Yes, both have advantages and > disadvantages. With provider-side filters, you can do things that are not > possible in QGIS expressions (such as complex PostGIS functions), while > QGIS expressions are more powerful when using variables, etc., and it’s > super nice that they are independent of the provider. I would still avoid > having a combination of both, as it seems fairly fault-prone and hard to > use. Using either one or the other seems right. I would for sure create a > QEP PR before I start. > > I’m not sure I understand you, Carlo, correctly. Are you talking about > creating query layers using QGIS expressions? If so, I’d prefer to keep > this aside for now. While it could be interesting, it would introduce a lot > of complexity, and I’d rather focus on filtering only. You can still create > a query layer — or a virtual layer — and then apply an expression filter to > it. > > Cheers > Dave > > On Wed, Sep 24, 2025 at 11:43 PM Carlo A. Bertelli (Charta s.r.l.) < > [email protected]> wrote: > >> Very interesting indeed. >> When I worked with Mapinfo, maybe 40 years ago, I remember using the >> "MapBasic" window to build query-generated layers. >> I think it would be very handy and substitute generating lots of >> geometric views inside the database (what a mess!). >> As Alessandro says, there are drawbacks in any solution, but operating >> the query inside the database (storing the query as a sort of "local view") >> is really much more efficient and does not require duplicating the backend >> via Spatialite with a lot of network traffic and cache size (see what >> happens with joins made at the client level in Properties). >> Meanwhile, the Query Builder is much more convenient and using the same >> syntax all the time is a good idea, but it could be optional, letting the >> user decide what to do. >> Anyway, this means creating "automatic temporary tables"; reducing them >> to filters only means missing some opportunities. >> I think we must make an effort to define use cases in a more rigorous >> way. I see a fuzzy scenario with possible misunderstanding between >> geodatabase parlance and GIS concepts, between application structure and >> use cases. Maybe it's only fog inside my mind, but the long gestation about >> the Query Builder suggests that I am not alone. >> Thanks for keeping reasoning on these issues. >> c >> >> >> On Wed, Sep 24, 2025 at 8:54 PM Nyall Dawson via QGIS-Developer < >> [email protected]> wrote: >> >>> >>> >>> On Wed, 24 Sept 2025, 10:56 pm David Signer via QGIS-Developer, < >>> [email protected]> wrote: >>> >>>> Hi there >>>> >>>> I've been considering enhancing the Query Builder (accessible via Layer >>>> -> Filter...) by QGIS expression based filters. At least with project and >>>> global scope. >>>> Maybe with tabs to distinguish between "provider side filter" (current >>>> functionality) and "expression filter" (new functionality). >>>> >>>> Any opinions on this? In my view, this could be valuable because it's >>>> available on all kinds of data-layers and allows us to use variables and >>>> functions for filtering as well. >>>> >>> >>> Can you make sure you file a QEP before starting any work? 👍 >>> >>> Nyall >>> >>>> >>>> Thanks for any feedback and cheers >>>> Dave >>>> >>>> -- >>>> >>>> Dave Signer >>>> Senior Developer & INTERLIS Architect >>>> OPENGIS.ch - Team QGIS & Industry Solutions >>>> >>>> _______________________________________________ >>>> QGIS-Developer mailing list >>>> [email protected] >>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> >>> _______________________________________________ >>> QGIS-Developer mailing list >>> [email protected] >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- -- Andreas Neumann QGIS.ORG board member (treasurer)
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
