status changed; resolution set
status changed from new to closedresolution set to fixed Done at r7548
View Articlesummary changed
summary changed from typmod support for PostGIS geometry to typmod support for PostGIS geometry - make geometry_columns a view
View ArticleArticle 39
That's why we have in old model POINTM etc. So POINT in old was for XY, XYZM and POINTM was for the POINT XYM case. So you saying I should keep as is. But I thought you wanted things to look pretty so...
View ArticleArticle 38
Sorry to revisit this, but I just noticed (duh) that geometry_columns as a coord_dimension column which partially removes the need for the type column to include dimensionality signifiers like ZM. So...
View ArticleArticle 37
I think we'll have enough of these that we need to separately document them in some detail. See ./MIGRATION
View ArticleArticle 36
Okay will do that then and then test with QGIS to see if it coughs up blood at the sight of change in casing. This could be more indepth breaking change even for 2D, but it's prettier :)
View ArticleArticle 35
Yes, agree with your general approach, and would like to go with mixed-case types with no ST_ prefix (eg MultiPolygonZ) for type information, because I just think it's prettier.
View ArticleArticle 34
Fair enough. I had my reservations as well especially since we don't have an ST_Information_Schema either. One thing that does have to be decided though, is it going to be POINT (4 dimensions in the...
View ArticleArticle 33
I'm fairly strenuously opposed to st_geometry_columns, in any form. We're hopefully jettisoning old scruft at 2.0, because we know we're going to have to live with 2.0 for a long time. And I don't...
View ArticleArticle 32
BTW: I'm still for having both a geometry_columns and an st_geometry_columns, but my reason for both has changed. As I said the st_geometry_columns is defined in the SQL/MM specs so if our objective...
View ArticleArticle 31
FYI: I think I can fix the view issue with constraint based non-adorned geometries, but it's a given that for more complex views to be registered properly(including those using typmod geometries) some...
View ArticleArticle 30
Okay I committed the change I discussed abovee at r7450 There is one issue that is bugging me. That is our new types do not display in a backwards compatible way. As far as speed goes, I have to test...
View ArticleArticle 29
Mark, We haven't yet -- that's what he meant by "Rubber will hit the road in deciding how to ditch the table. " My somewhat controversial solution -- which I will submit soon is. 1) Have no table just...
View ArticleArticle 28
Paul - which approach did you go for in the end? I can't work out from your comment in this ticket or the commit message which solution you went for :(
View ArticleArticle 26
Okay I've committed my uncontroversial change which corrects the f_geometry_column and also filters to only show tables and views. For my more controversial ones, you want me to just include as patch...
View ArticleArticle 24
Paul, hmm f_geography_column -- REALLY? Me thinks you copied too much. Anyrate once I load up some data -- I'll submit patches so don't worry about it unless you feel the urge to correct. I was...
View ArticleArticle 23
Well, was almost as easy as expected... at r7409. None of the supporting PL/PgSQL functions has been touched, and right now geometry_columns is still a table while geometry_columns_v is the view. The...
View Article
More Pages to Explore .....