I think there’s some confusion here. Cursors are a specific structure the server has defined, and should be considered opaque from the client’s perspective - if the server returns a cursor you can pass it back in follow-up requests to get the next page of results. The client does not know what the cursor contains and cannot construct its own.
Additionally cursors are not SQL queries. What you’ve pointed out is where the final query is constructed but this is not done using any client input directly, if you check where that code is called from it’s after many layers of decoding and validation. Allowing clients to specify raw SQL queries directly is a massive security risk and Nakama does not allow this in any of its built-in features.
To sum it up what you’re describing is impossible to do with the
What you’ll need to do is create your own RPC function that already contains the correct SQL query (do not allow clients to submit their own) and clients can invoke to return data they need. The query you’ve suggested could be part of the RPC but note that it does not perform a cursor-based operation.
The idea of cursor-based queries is to return a small set of results plus a “cursor” if there are further results available on request. Callers can then submit a new request with the cursor, and get the next set of results and a new cursor. This is a very efficient pagination mechanism that does not suffer from the typical offset+limit query serious performance problems.
As a small pseudo-example, in your case you might
"select * from ... limit 10", and encode in your cursor the ID of the 10th item. The next request would then become
"select * from ... where id > 'id of 10th item' limit 10" and so on. Your aim should be to give the database engine a way to quickly find the place to resume scanning from, assuming you’ve also given it an appropriate index to rely on. You need both an appropriate query and an appropriate index to make this work as intended.
This topic is a bit beyond standard Nakama usage but I hope this is helpful.