Hi,
Jose Orlando Pereira wrote:
> Sorry, stuff was put twice in the zip file making it somewhat confusing. It is
> in postgresql-g-0.1/javasrc/GordaInterfaces/docs/gapi.pdf or directly on the
> web site at http://gorda.di.uminho.pt/download/reports/gapi.pdf.
Thank you. I've just had a quick glance at it.
> Can you point out why is it [limiting], given that it is admittedly quite close?
An API is always limiting. And if you have to change the API a lot, to
fit your needs, what's the point in using it at all? Good APIs don't
change a lot.
Even if it's quite close, I estimate the effort to port Postgres-R to
use your API to be quite large. I.e. the first missing thing that came
to my mind was the ordering of processes when waking them up after
waiting for a lock. Postgres-R needs the processes to be woken up in the
order of writeset arrival.
Now, I didn't see anything related in the patch, but the gapi.pdf has
'Predictable Deadlock Handling' in it. I need to take another look...
> We'd rather discuss specific issues instead of the general topic of whether to
> build APIs around them. We certainly are not married to the proposed
> interfaces, although the functionality they capture does reflect our
> experience with several algorithms.
I still feel that I would need ways too many hooks. Especially when you
consider advanced replication features such as data partitioning and
remote query execution.
What also worries me is the use of triggers. ISTM that using triggers is
not deep enough in the database. In the above example, do I really want
to fire a trigger every time the database needs to wake up a process? In
PostgreSQL a trigger normally runs within a transaction. How do you work
around that?
I'm operating a level deeper with Postgres-R and really enjoy the
freedom I have with C. Having to write a hook or trigger for every
change in the database systems seems a lot of work, which I tend to
postpone until such a thing is really needed.
Regards
Markus
