auto-detection of postgres primary key field

[artemp]

With postgres, a key_field provided by the user is currently necessary for ensuring that the postgis plugins feature.id() is globally unique. When not provided the feature_count is simply incremented for each query and used to populate the feature id value for each feature (so feature id's are not unique across queries).

Ideally we could support auto-detection of primary key so that we can promise, when possible, globally unique feature id's.

Since globally unique primary keys are not needed for normal rendering usage the current behavior (of not requiring a primary key and simply incrementing the feature counter) will be maintained (even though this is unique behavior to postgis.input).

But a new option autodetect_key_field will be added that will trigger the autodetection behavior and then mapnik will throw if no valid primary key can be detected (and if none is supplied).

[artemp]

[springmeyer] see also #821 for sqlite

[springmeyer]

ctid appears useful as a default: http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html

[springmeyer]

re-opening, there was a flaw in this work that breaks the common and widespread usage of subquery syntax for rendering (where a primary key/id field is rarely used). Basically the problem is that its common for subqueries to be written like table="(select way from planet_osm_line) as t" and if we autodetect osm_id and append it then the final select mapnik forms up will fail because osm_id is not pulled in the subselect.

[springmeyer]

b7f714f - rolls back to current behavior whereby no primary key will be autodetected (and added to the final query) unless explicitly requested. closing.