2. adding any of the functions enlisted in the notes for the new report formats will result in the syntax error message.

EXAMPLE:

SELECT
   tkt_id AS '',
   title AS 'Title',
   user() as 'User'
 FROM ticket

will result in the syntax error msg.

information about the Fossil version (command: fossil version) at Windows XP with all recent updates:

This is fossil version d5695157d0 2009-11-11 16:21:19 UTC 

anonymous added on 2009-11-25 22:30:34:
the sql query:

SELECT
   tkt_id AS '',
   title AS 'Title',
   user() as 'User'
 FROM ticket

Syntax error: no such function: user

anonymous claiming to be btheado added on 2009-11-28 21:35:42:
I also noticed how these sql functions are missing from the current fossil implementation and I took a stab at porting some of it over from cvstrac.

Both user() and cgi() both were straightforward.

The code for aux() and option() is more complicated. Maybe it will also be straightforward, but I haven't looked close enough yet.

I looked at the wiki() implementation in cvstrac and the functionality doesn't really seem like a good fit for a sql function. The function only prefixes the cell values with a special string that later triggers wiki conversion (and bypasses html escaping as for other normal columns). With this behavior, I don't think 'wiki()' can be combined with other sqlite operations very well. If the user wants to perform additional modification to the output of 'wiki()' with another sql function, then they would likely be surprised to find at the sql level that the output of that function is not the wiki converted text. I don't see a use case for doing that, but it makes it seem to me like it is a bad fit for a sql function.

So I took the approach of adding a new special column name prefix. If the column name is prefixed with the string '_wiki_' then the cells in that column will be wiki converted and the '_wiki_' prefix will be removed from the column name. All other column names prefixed with '_' will trigger the "new row" functionality as before.

What do you think of this approach?

I have these changes checked into a local clone of the fossil repository. I created my own branch for these changes, but then accidentally checked the changes into the trunk (I'm not well versed with the VC side of fossil yet). I'm not sure yet how to fix that. I guess I can just start over with a fresh fossil clone and make the checkins again.

Are you interested in having these changes pushed into the fossil repository?

anonymous added on 2009-12-03 01:20:52:
I would like to see the user() functionality. I want to generate a report that shows all of the tickets assigned to the current user, but without the user() functionality I'm not sure how to do it. It's odd that the instructions for generating a ticket report explicitly show a number of functions that are not available.

drh added on 2009-12-17 15:24:03:
Check-in 4b0d2fbefbd5955b6769a8bd8b4c941b078b27af