#16455: Postgis 2.0 Compatibility
-------------------------------------+-------------------------------------
Reporter: ckarrie | Owner: jbronn
Type: New feature | Status: reopened
Component: GIS | Version: master
Severity: Normal | Resolution:
Keywords: postgis 2.0 | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by fcurella):
* status: closed => reopened
* resolution: fixed =>
* stage: Ready for checkin => Design decision needed
Comment:
I'm reopening this ticket instead of creating because most of the
discussion is in here.
The ticket was closed in 92b5341b19e9b35083ee671afc2afb2f252c662d, but
it's been partially reverted in
91ef2a5253a50a602523bdda943c32c4cfe719fe[1].
The crux of the dilemma is how users are supposed to create a spatial
database on which version of postgis and postgresql.
There are two way, both supported as postgis2.0:
1. the classical way: creating the new database from a template database.
2. The new way: creating the new database (without having a spatial
template), and then creating extensions on it (note that this will only
work on postgresql 9.1+)
I think we should support both ways.
The original implementation of this patch used to query the database
looking for the template database and using it if found. Otherwise it will
assume the user is trying to go the 'create extension' way.
This means one additional query on creation[2], which obviously is not
optimal, but I can't see any way around it.
91ef2a5253a50a602523bdda943c32c4cfe719fe reverts this in that it assumes
there's always a template database available. Indeed, creating a database
will fail with it.
First step would be to determine if the cost of the additional query is
worth it. If it isn't, we should update the docs to instruct the user to
create the template database regardless of what version of postgresql or
postgis they're using.
---
[1] Only the code has been reverted. The documentation hasn't been updated
to reflect it.
[2] The original patch had a suboptimal implementation of this which would
query per-table. I have opened a pull request so that it will be one query
per run. https://github.com/django/django/pull/439
--
Ticket URL: <https://code.djangoproject.com/ticket/16455#comment:57>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
