Python and PostgreSQL make an unbeatable combination of processing power and persistent data storage. The Python language provides superior expressive power for solving problems in very diverse fields -- from web services to numerical analysis. PostgreSQL supplies a high-integrity, reliable database that ensures continuous availability of the information you need to solve those problems.

This introductory talk will show how to use the Python Database API Specification v2.0 to:

1. Connect to a PostgreSQL database.
2. Execute simple queries.
3. Execute queries with parameters from your program.
4. Fetch query results from the database.
5. Delete or update database tables from your program.

When writing my DDL statements I like to document them with javadoc inspired comments. The "pgcomment" tool will convert those comments into "COMMENT" SQL statements, so the comments are present inside PostgreSQL. Optionally you can convert the javadoc to LaTeX or HTML.

This talk is about the many advantages of using PostgreSQL in your company.

With the advent of neogeography everyone wants to do something spatial with their applications. In this session I will give an introduction to PostGIS (a spatial blade for PostreSQL) and then show you how to get some cool mapping magic going. We make sure your PostGIS install is working, download some data from the internet, load it into PostGIS, and then start asking some interesting spatial questions of the data. We will look at queries calculate distance and area, calculate centroids, test distance or containment, and we will clip features to a bounding box. Demos and code will be shown for using these functions in desktop applications and in custom applications.

(NOT THE ABSTRACT) If you do not receive a workshop submission we can do this as more hands on and have some more fun with it. I am willing to do this if you receive nothing else but right now prefer to only commit to an hour but can do more. If so then people should sign up for accounts on the deCarta devZone http://developer.decarta.com so we can do some live coding.

Having trouble crafting a high-availability solution without excessive performace costs? Then this is the solution for you. In this session we will discuss and implement the Userland Implementation of the Common Address Redundancy Protocol (UCARP) along with PostgreSQL's "warm standby" feature and Distributed Replicated Block Devices (DRBD) to provide rapid recovery from database failures while still retaining the ACID "durability" constraint.

Available for many major Unix/Linux operating systems, UCARP is a lightweight, easy-to-manage solution to provide redundant services on a network. This means that we can have two systems that sit behind a switch monitoring one another. When one system goes down, the other can take control and continue to provide services with minimal downtime.

Of course, UCARP only provides a partial solution to this dilemma. Using Distributed Replicated Block Devices we could provide for redundancy of the entire PGDATA directory structure. Since DRBD of the entire PGDATA directory doesn't scale well, we will learn how to implement a "hybrid" solution, providing transaction durability through the use of DRBD on PostgreSQL currently-in-use "WAL" logs, and continuous WAL recovery.

You'll also learn how UCARP compares and contrasts to using Linux Heartbeat (v2) and Object Cluster Framework (OCF) resources.