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

[John Ralls]

> On Mar 14, 2015, at 8:05 PM, Sébastien de Menten <sdementen at gmail.com> wrote:
> 
> 
> 
> On Fri, Mar 13, 2015 at 2:37 PM, John Ralls <jralls at ceridwen.us <mailto: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 <https://www.sqlite.org/c3ref/create_function.html>). 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 ?

Maybe, though storing as a string is going to make it pretty slow. Isn't there a way to store an arbitrary binary?

There's also a portability issue. We want to be able to use the same code to do the same things on all supported SQL backends.

Regards,
John Ralls