As always, your inputs are most appreciated. I am not surprised to see the ST_GEOMETRY implementation but I find myself more interested in seeing how much I can really do with the PostGIS type.

With regard to the standard, you and I are in agreement. The comment about using ST_GEOMETRY if you’re targeting multiple platforms was actually their words although, now that I look at it again, I didn’t make that clear. I chuckled at the idea of using a proprietary type to achieve cross platform consistency.

Thanks again. Your comments are great information.

1. Is correct, and nice to see that ESRI has done what is probably the right thing and installed in their own schema. This will require them to alter the search path for SQL clients to find their functions, which won’t be a problem when the client is an ESRI product, but might be confusing to users connecting to the database directly with psql or pgdamin.

2. The point of the standard is that you don’t need one vendor in order to get cross-database compatibility. When we heard ESRI was interested in PostgreSQL, we implemented all the function in their existing SDE/SQL documentation, so they would have 100% compliant SQL available if they chose to use PostGIS.

3. PostGIS has Arcs, but the utility of them is as fraught for us as they. If you have to linearize them to use them… the point is?

4. There are a couple SE_ functions in the ESRI implementation that return their own binary serialization instead of WKB. If it really is a Huge Performance Win, then moving to compressed arrays in PostGIS might be worth while. I’ve been thinking that since the disk array stubbornly remains the slowest part of the server hardware stack, that this might be the next obvious target of optimization. Note that if ESRI failed to be terse in their header definitions, they could blow away all the advantages of their compression schemes quite quickly… but we’ll never know that.

5. The ST_GEOMETRY will use the PostgreSQL GiST framework, the same one that PostGIS uses, but their index binding is all their own. The GiST framework is a PostgreSQL infrastructure that extensions, like PostGIS and ST_GEOMETRY all use for indexing.

6. You can create PostGIS geometry table with a simple CREATE TABLE, the only penalty is that you don’t get your GEOMETRY_COLUMNS table auto-updated with the right metadata. ESRI simply forces you to fill in their metadata tables by hand, a great leap forward. (The metadata tables are a PITA, I wish there was a nicer solution.)