Topics discussed:

• Graham's question was whether, once a server knows about some view definitions, you could build a SQL statement into the RESTful API and refer to a view by name. John Grimes said nothing rules it out — the group has discussed views known to the server and ways to run queries over them, just never how to expose that to the rest of the FHIR API. Gino Canessa's answer was blunter: passing SQL in over a REST call terrifies him, and the chance he would execute any SQL submitted that way is zero.
• Gino's counter-proposal was to reuse named queries, the existing search mechanism where an OperationDefinition is invoked through _query and does the filtering that ordinary search parameters can't express. A named query would map to a view definition or a stored procedure, which hides the SQL behind something pre-compiled and indexed. Steve Munini liked it much better than query=select something, noting that half the penetration-testing tools on the market would reject the latter on sight.
• John Grimes suggested FHIRPath might be the better advanced search syntax — several implementations including Pathling already allow arbitrary FHIRPath filters unofficially, and since every search parameter in FHIR is defined in FHIRPath anyway, an engine gets you all of them for free. Gino shot it down on grounds of who has to build it: EMR vendors have no FHIRPath engine and no FHIR store, they map search into their internal structures, and doing that against arbitrary FHIRPath at runtime is a non-starter. He'd already tried to standardise inclusion filters and been told by every large vendor that they had their own way and weren't interested.
• Brian Kaney's proposal to reuse Library rather than mint a query resource got a first look. The base64 attachment drew most of the complaints — Gino explained the dual encoding is a fallback so systems that don't understand the expression extension still get something, but agreed the encoded copy is far less useful than plain text, and that the real culprit is Attachment losing its plain-text slot. John Grimes considered the packaging question orthogonal: the hard problems apply either way, and Library is fine for queries.
• The hard problem is that SQL is only interoperable if you can say which SQL. Bashir Sadjad hoped that flat views plus ANSI SQL would be enough, since it avoids the exotic features. John wanted to know how you would actually verify that — not just that an instance is structurally valid, but that it sticks to whatever constraints you put on the SQL itself, and whether that's even tractable. Gino thought not: JSON functions, ANSI versus Oracle joins, the AS keyword, fifteen dialects in any formatter you pick — and suggested sidestepping it by treating the SQL as a description rather than something you promise to execute.
• Bashir Sadjad reported from DevDays on a German group doing text-to-SQL against the nested FHIR schema rather than flat views. Their route turns out to resemble this group's: pull FHIRPath expressions out of the text first, then use templates to turn each one into a SQL fragment. Bashir's own talk covered generating SQL over flat views with GenAI, and his read was that going straight at the wide schema leaves you bogged down in the SQL.