Phil Mayers wrote:
Alternatively, just enforce that the SQL query has to return:
select attrname, op, val from ...
...i.e. returning
request:Foo | := | bar reply:Class | := | baz
That's pretty much what Arran and I ended up with. The downside is that we'll have to create a new internal expansion API, as the current one only deals with strings. Then the question becomes what syntax to use, to signal using the new expansion. The input is a string, containing an SQL "select" statement. The output is a list of VPs. So... the only syntax I can thing of which makes sense is: update { reply += "%{sql:SELECT ...}" } i.e. when the destination is a list, the new expansion function is used, instead of the old on. This is easy to discover in the code. This syntax is similar to what Arran already added: update { reply += `/path/to/program` } So there's precedent. I think that functionality will be very useful. I know in the systems I build, I sometimes have to go through contortions to get multiple fields out of SQL and into attributes. Alan DeKok.