PostgreSQL Summer Projects
The PostgreSQL Project is excited to take part in the Google Summer of Code 2008 program. This program endeavors to fund students to contribute to an open source project over the summer break.
Example Proposal Ideas
The PostgreSQL Project has a wide range of opinions on what it feels are acceptable SoC projects. The examples listed here are meant only as a suggestion of things we would likely find useful, but you should not feel obligated to pick from this list by any means. If you have just discovered a new algorithm as part of your thesis work, we would love to see a proposal implementing that in PostgreSQL. The point is that all proposals will be evaluated on their own merits, so be creative.
Core Source Code
- TODO Items: A number of the items on our TODO list have been marked as good projects for beginners who are new to the PostgreSQL code. Items on this list have the advantage of already having general community agreement that the feature is desireable. These items should also have some general discussion available in the mailing list archives to help get you started. You can find these items on the TODO list, they will be marked with a percent sign (%).
- PITR Improvements: Allow point-in-time recovery to archive partially filled write-ahead logs and automatically archiving them when pg_stop_backup() is called or the server is shutdown. Allow stand-by server to allow read-only queries to be run concurrently while replaying wal logs
- DDL Functions: Create a SQL-callable function capable of generating DDL scripts for objects within the database.
- EXPLAIN Enhancements: Add information to EXPLAIN documenting I/O activity, discarded plans, costing detail, memory usage and more.
- XML Indexing: Add special indexing types for XML data, capable of supporting indexed XPath queries.
Infrastructure
- Enhance Buildfarm to test external packages, patches, or performance: The PostgreSQL project maintains a public buildfarm that continuously communicates with several machines that checkout and build the PostgreSQL source on a regular basis. The idea behind this project is to extend the current buildfarm code to allow it download external modules and report back on their build status, to download unapplied patches and test them, or to run performance tests.
External Applications
- pgAdmin III / phpPgAdmin Enhancements: PostgreSQL supports a number of popular GUI Tools that are not distributed with the core project. Projects like these often have their own TODO lists and compatibility issues with the core PotgreSQL that need development. Some ideas for pgAdmin III projects include:
- A graphical query builder
- A data loader, to allow import of data (and tables where appropriate) from CSV, ODBC, libpq etc. Field mapping and data transform functionality, perhaps using Python functions.
- An ER diagramming tool with the ability to reverse engineer a schema as a starting point.
- Allow registration of non-PostgreSQL servers for browsing in the treeview via ODBC. No DDL need to be supported in the main GUI, but the Query Tool and Edit Grid should be usable. Also consider the ability to copy tables and data to a PostgreSQL server.
- A 'diff' utility to show the schema differences between two databases and output an upgrade script.
- Procedural Language Improvements: PostgreSQL provides support for more than a dozen different procedural languages, however the level of support varies depending on the language implementation. Enhancing support of these procedural languages might include fixing build issues, adding SPI support, adding trigger support, adding support for IN/OUT parameters and more.
- Replication: PostgreSQL provides a wide range of replication solutions for varying types of replication needs. Many of these projects need assistance with building against different versions of PostgreSQL, installation and setup, administrative tools, and general bugfixing.
- Teaching & Learning Tools: External tools to help in teaching the internals of PostgreSQL such as enhanced visual EXPLAIN, graphical models of the query engine, educational guides to the code, and interactive tools to demonstrate various query types.
Additional projects may be found by browsing the PostgreSQL Development Projects website.
Mentors
PostgreSQL follows an open community development model, so student projects are likely to be reviewed and commented on by any and all members of the PostgreSQL community. This also means that we may be able to find mentors for additional projects by reaching out to this community. If you are interested in working on a project not explicitly mentioned above, you may
want to contact one of the Summer of Code liaisons below about writing a proposal.
- Josh Berkus <josh @t agliodbs.com>, Sun Microsystems, USA
- Selena Deckelmann <selenamarie @t gmail.com>, Chris King Precision
Components., user groups and applications
- Jonah H. Harris <jonah.harris @t gmail.com>, EnterpriseDB, query engine
- Alvarro Herrera <alvherre @t alvh.no-ip.org>, CommandPrompt Inc., core code
- Heikki Linnakangas <heikki @t enterprisedb.com>, EnterpriseDB, core code
- Dave Page <dpage @t pgadmin.org>, EnterpriseDB, pgAdmin, GUI tools, and Windows
- Greg Sabino Mullane <greg @t turnstep.com>, Endpoint Corporation, Perl driver, Perl-based projects
- Julius Stroffek <julius.stroffek @t gmail.com>, Sun Microsystems, query engine and applications
- Robert Treat <xzilla @t users.sourceforge.net>, OmniTI Inc., PHP-based projects and infrastructure
- Zdenek Kotala <zdenek.kotala @t sun.com>, Sun Microsystems, file format and upgrade utilities
If your project is not selected for funding by Google, but you still think you have a
feasible project proposal, then please email our developers mailing list at pgsql-hackers@postgresql.org.
Proposal Guidelines
Students are responsible for writing a proposal and submitting it to Google before the
application deadline. The following outline was adapted from the Perl Foundation open source proposal
HOWTO. A strong proposal will include:
- Benefits to the PostgreSQL Community - a good project will not just be
fun to work on, but also generally useful to others.
- Deliverables - It is very important to list quantifiable results
here
- Project Schedule - How long will the project take? When can you
begin work?
- Bio - Who are you? What makes you the best person to work on this
project?
Please also see our additional Advice to Students before submitting a proposal.
We would prefer that development discussion occur on our project mailing lists when possible, with special recognition being given to those students who vet their proposal with community developers before submitting their proposal to Google SoC. This is not required, but can have a large impact on the chances of your proposal being accepted, so please don't be shy. In any case, you will be required to keep open lines of communication with your mentor should you be accepted, so if you have circumstances that may affect this, please explain them up front in your proposal.
Previously Accepted Projects
- Enhanced Aggregate Support
- Full Disjunctions
- Hashing DISTINCT Clause Implementation
- ECPG Cleanup
- Initial support of XMLType for PostgreSQL
- phpPgAdmin improvements
- xlog viewer
More information on these projects can be found on Google's PostgreSQL SoC page.
Frequently Asked Questions
-
Am I eligible?
Please see the Google Eligibility FAQ
for all questions about eligibility.
-
When is the proposal deadline?
According to the Summer of Code FAQ, the deadline for submitting student proposals is March 31st, 2008 (00:00 UTC). Please remember that proposals must submitted to Google themselves, although we are happy to discuss any proposals with you ahead of time.