Re-working GNCId: removing GNCIdType enum

Linas Vepstas linas@linas.org
Sun, 25 Nov 2001 15:08:20 -0600


On Sat, Nov 24, 2001 at 04:53:08PM -0800, Dave Peticolas was heard to remark:
> On Sat, 2001-11-24 at 16:19, Derek Atkins wrote:
> > backend/postgres/events.c
> 
> This one is complicated, we would have to make a general
> mechanism for detection events for the other, newer types.
> This would probably need to be part of the backend extension
> mechanism.
> 
> 
> > backend/postgres/gncquery.c
> 
> Here I'm not sure using other types besided
> accounts, transactions, and splits would
> make sense, unless guid Queries are extended
> to handle new types.

I see that the minimal changes to make this compile & work for now 
have been checked into cvs.  Lets defer discussion of other changes 
till we solve the higher-level problem of actually storing the new 
objects.

My goal is to not have to write a hand-tuned, pure-custom-vlsi
backend for each and every new busienss object.  I'd rather create 
some config-file-driven thing, that will autogenerate 'the right thing'
either at compile time, or at run time, and still have good/excellent
query & table-join performance. 

The crap with the m4 macros was a weak step in that direction,
its just m4 is not the right technology.   I think I know how, but
it won't be quick or easy.  Plus, I've got mixed feelings on a 
'do-it-myself' approach, vs. finding something else on the net that
already does much of this ...

> > engine/Query.c

The queries need to be extended in a general way.  An earlier note
described how.

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933