From: | "Sameer Mahajan" <Sameer_Mahajan(at)symantec(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | postgres wish list |
Date: | 2009-02-19 06:04:42 |
Message-ID: | 14EB9817E621764ABEEC72425A419D84013227C9@PUNAXCHCLUPIN07.enterprise.veritas.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Yi Zhao | 2009-02-19 06:27:12 | how to do this select? |
Previous Message | Mike Christensen | 2009-02-19 03:58:03 | Removing a corrupt database by hand |