|
I recently worked on rewriting a fairly complex Berkeley DB
based system using Postgres DB. Following is a wish list and a brief explanation
for each of those items for postgres. It is not necessarily a comparison of
postgres functionality with that of Berkeley DB but some required useful
functionality currently lacking in postgres. I would like to have some
feedback, comments, suggestions regarding these. ·
Shared memory based connectivity: As such
postgres has client – server model. The TCP-IP nature of its connectivity
further adds to the latency of this communication. It will be nice to have a
shared memory based connectivity between libpq front end and the back end. ·
Extended SQL functionality o
Unsigned data types: It would be nice to
have native support for unsigned flavor of simple data types (e.g. integer) o
Nested transaction funtionality: I followed
quite a few discussions stating postgres considering it at some time but later
abandoning it due to some complexity. The “savepoints” are also
believed to provide similar semantics. However it is useful and handy to have
the simple nested transaction syntax and functionality. ·
Cursors o
It would be useful to have updateable cursors.
Otherwise the application is required to figure out a required INSERT versus
UPDATE amongst other things. o
Berkeley DB has various positioning (e.g.
DB_SET_RANGE ) as well as operational (e.g. DB_NOOVERWRITE) options in
its cursors. Postgres can provide such functionality (e.g. using underlying
btree for an index to give DB_SET_RANGE like positioning) very easily. ·
Configurable error handling control: in
case of fatal errors the transaction is aborted by default. It would be useful
to make some configurable options available for the application to control the
error handling in such situations. Berkeley DB has an option where all the
exceptions can be turned off and the system returns only error codes which are
then required to be handled by the application. Thanks, Sameer
Mahajan Office: +91 (20)
4075-4106
|
