Using an externally hosted postGreSQL as a gnu cash backend?

[Dean Gibson]

On 2016-04-11 12:51, Colin Law wrote:
> If you are hosting PostGres on a machine connected to the internet 
> don't forget to consider all the security implications. You don't want 
> anyone getting into your machine via the open ports, or of accessing 
> your data if you have not got it right. For example, if you connect to 
> a pg server are the user and pwd encrypted or are they open for anyone 
> to snoop between you and the server? I don't know the answer to that.

You can easily set up a PostgreSQL server using an SSL connection and 
certificate.  The user/password and all the data is encrypted. That's 
how I've been running PostgreSQL in another application across the 
Internet for five years, and it *works very well*. In this instance, it 
is the *right tool for the job*.  In addition, I've been PostgreSQL for 
other web-based applications for over a decade, one of which won me an 
award (since we're mentioning experience & qualifications in this 
thread).  I've also been programming computers since 1962, and am now 
retired.

However, when I learned that GnuCash just uses PostgreSQL as a data 
store without incremental transaction posting, it was obvious to me 
that, given how it is being used in GnuCash, PostgreSQL was *the wrong 
tool for the job*.  I chose the compressed XML format, and have been 
using it for the past four years.  My only complaint is the speed of 
loading, which I suspect is more of a data parsing issue than anything 
else.

 1. The XML format provides an easy (albeit slightly bulky) and reliable
    backup mechanism:  You can manage it yourself, and you know exactly
    what you have (and where).
 2. In my opinion, in order for PostgreSQL to be the right tool for the
    job, not only should it be used with incremental posting, but
    superseded or deleted transactions need to be archived, either in
    the database or logged separately, in a manner that preserves the
    integrity of the data.
 3. In addition, an incremental SQL-based solution may have performance
    issues, unless it is carefully designed.  GnuCash appears to use an
    in-memory model, which seems appropriate for anything but a large
    business.

I (and probably like many others) *would really like* to see GnuCash 
data in an SQL database, with an easy-to-use schema that would allow a 
*great amount of flexibility* in creating custom reports, data mining, 
etc.  However, until GnuCash changes in a manner to address my concerns 
above, an SQL database as the data store seems more of a burden than a 
useful tool.

ps: I hope the HTML-formatting gets stripped ...