From PostgreSQL wiki
Information about Kevin Grittner and his activities.
Kevin is currently employed as a database administrator with the Consolidated Court Automation Programs (CCAP) at the Wisconsin Court System. He's been making a living in the computer industry since 1972. He started a consulting company in 1980 after working in data control, operations, programming, systems analysis, and design. He was finally lured back to employee status in his current position after more than a quarter century of consulting.
Kevin has experience with many types of applications in many types of organizations, businesses, and government. In 1984 he was the architect and primary author of the PROBER database and development system, used by thousands of corrections agencies, health departments, hospitals, and fire departments around the world. (The last known use was a statewide health department which converted off the product in 2006.) He has also developed application development platforms used by clients to speed development, improve standardization, and provide portability.
Current Work In Process
Declarative materialized views
For the 9.3 release.
Possible Future Work
Rewrite tsearch parser to use regular expressions
In reviewing a patch to fix some performance problems in the current parser, I became interested in the possibility of rewriting the current state machine implementation with a regular expression implementation.
Deleted WAL files held open by backends in Linux
I wasted some time tracking down an oddity which is more of an annoyance in system administration than a real problem, but might look at cleaning it up to save others the bother of investigating the issue.
Temporal data improvements
Temporal data handling is weak in SQL in general, and the PostgreSQL implementation seems skewed toward scientific or engineering applications, leaving it weaker than some databases on business applications. (One example would be clean handling of monthy payment schedules.) Enhancements to this area might be interesting.
LSB script compliance
I came up with a pretty LSB compliant script for Linux; however, the community feels that most of the logic handled in the shell in this script should be moved into pg_ctl. There's a pretty long and winding thread on the topic. The last version of the script might be useful to identify what issues need to be covered in the current pg_ctl code.
There have been a few posts to the lists about specific use cases where TOAST defaults are far from optimal. Allowing some tuning here might be helpful.
Literal and NULL handling anomalies
There are a few corner cases where differences between standard and PostgreSQL behaviors with string literals or NULLs astonish those new to PostgreSQL. These aren't easily solved, but might be worth the effort.
Language is not always as readable as it could be, and some files still largely read like proposals for features which are now implemented.