[mapserver-users] Hacking Mappostgis.c to allow Views as Mapserver Data Source

[Dave Blasby]

Sean, 

	Thanks a lot for your comments and work on the mappostgis.c
connector!   
Its always great to see someone contributing!

Sean Gillies wrote:
> 1. Querying a unique row ID called "URID" instead of the Postgres
>     OID.

The reason why I used OID was because it is always available in every
table, and is always unique.  Relying on a column called "URID" to
exist,
be an integer, and be unique is a pretty hefty assumption. Plus it 
requires people to manually add this column to every table.

As an alternative, you can check with msPOSTGISLayerGetItems() to
see if there is a "URID" column.  If there is, use it, otherwise use
OID.
This way only people with a "URID" column thats non-integer or
non-unique
will have problems.  

Perhaps we should call it "UNIQUE_INT_ID" so its highly unlikely someone
would
mistake what it is and what it should contain?

>     (Code in mappostgis.c presumes the geometry to be the last field
>     in the record, so you have to explicitly list columns in your
>     view definition in order to get the proper order.)

This shouldnt be the case - I explictly query the columns in
a particular order:

SELECT name,address,dollar_value,<geometry> FROM ...

The underlying database order of columns is unimportant (you can
even have more than one geometry column in your query).

Later on, I do make the assumption about the order of the columns
begin returned by postgresql - but that assumption is justified.

> 2. The code in mappostgis.c which parses the message from EXPLAIN to
>     get the query fields returns some bogus fields named "<>" from
>     a view.  So, I made a small change to throw out these bogus
>     fields.

Excellent - I hadnt noticed the false column names postgresql produces
when looking at views.  Strange - I'll definately add this patch in.


dave