postgres wish list

Поиск
Список
Период
Сортировка
От Sameer Mahajan
Тема postgres wish list
Дата
Msg-id 14EB9817E621764ABEEC72425A419D84013227FA@PUNAXCHCLUPIN07.enterprise.veritas.com
обсуждение исходный текст
Ответы Re: postgres wish list  (Craig Ringer <craig@postnewspapers.com.au>)
Re: postgres wish list  (Grzegorz Jaśkiewicz <gryzman@gmail.com>)
Re: postgres wish list  (Thomas Kellerer <spam_eater@gmx.net>)
Список 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 Mahajan
Sr Princ Software Engineer
Symantec Corporation 
www.symantec.com
                                                           

 

Office: +91 (20) 4075-4106


sameer_mahajan@symantec.com

                                                           

cid:image001.gif@01C95F60.3A312C10

                                                                               

http://syminfo.ges.symantec.com/marketing/globalcommunications/images/sig_green_bug.gif

 

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Yi Zhao
Дата:
Сообщение: how to do this select?
Следующее
От: Mike Christensen
Дата:
Сообщение: Re: Removing a corrupt database by hand