Setting up gnucash to use postgesql back end - close but no cigar ...

[Wm]

Sat, 14 Mar 2015 12:05:45 
<CAB2pxDu7PwLVGjnQn5P1a05zVu198RxpKYxQNBZMeAAzu3yWRQ at mail.gmail.com> 
Sébastien de Menten <sdementen at gmail.com>

>On Fri, Mar 13, 2015 at 2:37 PM, John Ralls <jralls at ceridwen.us> wrote:
>
>>
>> There are a couple of possibilities for the DB. I don't think it's
>> feasible to provide rational arithmetic in the DB engine. Grouping by
>> denominator is possible, but I think forcing the denominator to the account
>> commodity's maximum denominator (100 for most currencies and common stocks,
>> 10**8 for bitcoin, etc.) would allow addition and subtraction in queries,
>> and that will handle most of our needs. Anything needing multiplication or
>> division will have to be done in C++.
>>
>>
>I just saw (and tested) that it is possible to create new functions and
>aggregates in sqlite dynamically (
>https://www.sqlite.org/c3ref/create_function.html).

Sigh, but they'd be in that db not everyone's

> This could open the
>possibility to rewrite the "sum"."avg" aggregate in sqlite to handle
>properly decimals and store decimals as string in sqlite. For other SQL
>backend, the builtin decimal support could be used.
>Would this be a possible path for the future ?

Nope.  You haven't been listening.

Try LCD and work from there.

-- 
Wm...