PostgreSQL 9.3 Enhancements and Wishes from a PostGIS Developer POV   

Features already in place in 9.3 and how they help PostGIS

There are already features in PostgeSQL 9.3 that we think will be very beneficial to PostGIS users and the PostGIS development team.

• Binary output directly from PSQL - with the introduction of raster in PostGIS, it became possible to output images that were a result of various spatial processing steps. Unfortunately there was no easy way to dump out an image of these directly from psql without employing some hacks. Looks like Andrew Dunstan will be adding psql binary output to 9.3. Thanks Andrew. Still need to test this out.
• LATERAL clause: Both Andrew Dunstan and Depesz briefly covered this new feature. PostGIS has a family of functions called Dump functions which essentially expand out the components of a geometer/raster into sub elements, and the Tiger geocoder geocode function can also output one or more records of possible locations. The syntax for using these will become a lot easier with employing LATERAL. We are also hoping to see some speed benefits.
• Array Element Foreign Keys and add/remove syntax for arrays: NOTE to strk: -- read this one. I think these new feature will be very useful for PostGIS Topology support. It's hard to tell right now how useful this is, but it's on my radar to experiment with. For those who don't know, PostGIS has two (well really 3) kinds of spatial vector support. There is the geography/geometry which is really a denormalized view of vector data where ediges,nodes etc are duplicated so you can have a standalone geometry object. Topology is more of a relational view of vector data -- edges, nodes etc are not duplicated, but they know what geometries they are part of and ensure connectedness of a network of geometries. Topology uses numered arrays heavily, but it's tricky right now to ensure the element arrays map back to respective nodes, ediges, and faces.

When is PostgreSQL gonna have these?

There are still quite a few pain-points for us when developing PostGIS. I'll itemize just a few here we'd like to see.

• CREATE OR REPLACE AGGREGATE -

  PostGIS has a lot of aggregate functions for geometry, raster, and topology. Our upgrade generator handles Functions well since for the most part we can just CREATE ORE REPLACE them if they don't exist, and on rare occasions when things really change have to drop them. AGGREGATEs do not have comparable plumbing. So our script just DROPS them and recreates them. This becomes an issue if usese have built views against PostGIS aggregate functions.

• Extensions ability to control where to look for extensions - this is really an issue for testing. The make check process of PostGIS doesn't require PostGIS to be installed before testing. It essentially hard-codes thes test path in the functions for testing and only on install are the relative lib paths used. Unfortunately there is no easy way we can see to do the same for testing the CREATE EXTENSION plumbing without actually installing PostGIS. Having some sort of configuration variable to set this would be great.