#1095 closed defect (fixed)
revise MIGRATION document
| Reported by: | strk | Owned by: | pramsey |
|---|---|---|---|
| Priority: | blocker | Milestone: | PostGIS 2.0.0 |
| Component: | postgis | Version: | master |
| Keywords: | Cc: |
Description
I might be wrong but I think I saw geometry_column view definition falling back to using constraints, if available. The MIGRATION document says it doesn't.
Also, I'm not sure the new geometry_column would return the mixed case thing. It's important that this document is in sync with the real code..
Change History (4)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Strk where does the MIGRATION guide say geometry_columns don't use constraints. I think the confusion might have been where I said views built the old constraint way (when I should have said views with base tables built the old constraint way).
I hope I clarified this in 7561 and also tried ot change to 80 column.
Tables that use constraints are registered right. Views that are based on tables that used constraints do not get registered right since the constraints don't carry to the views. Views based on typmod geometry columns may or may not register right. They will if they are not passed thru geometry processing functions. They won't if you apply a processing function to them.
These can be remedied by casting them to the appropriate typmod type.
Oh… limiting the file to 80 columns would also be a good idea.