Opened 14 years ago
Closed 14 years ago
#918 closed defect (fixed)
two bugs in Populate_Geometry_Columns(oid)
Reported by: | nicklas | Owned by: | nicklas |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
From report by Anders Söderman that Populate_Geomtry_columns gives primary key violation in geometry_columns table
Populate_geoemtry_columns(oid) does not delete old entries in geometry_columns if the tabel or schema name includes characters that makes need of double quoting.
It is working when there is no need for double quoting because quote_ident don't quote when not needed.
Second bug is that that entries for views is not deleted at all before the function tries to add a new one which also causes a primary key violation error.
Change History (8)
comment:1 by , 14 years ago
Owner: | changed from | to
---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Well it's an implementation, not an interface. I think it's fine to backport to 1.5 and 1.4 branches.
comment:4 by , 14 years ago
The problem is not just our release policy.
How to get the changes into the database without running an update script which is supposed to not be necessary when doing a micro update.
comment:5 by , 14 years ago
Nicklas,
strk is right. It's okay to backport as long as it doesn't change the API interface (sql interface in this case). Meaning it requires no extra arguments or change of argument types.
That was partly why we went thru so much trouble in 1.4 having the update script check the svn r version instead of just the minor version. Though I'm not sure we spelled that out well in our by laws. Probably need it to do that. Anyway a precedent was set in 1.4 as I recall, so you are safe to backport.
comment:6 by , 14 years ago
ok
that means that you might have to run th update script on micro updates. I have missed that or at least mixed things up. I will do the backport when I get to a computor.
comment:7 by , 14 years ago
Yap. Unfortunately we didn't spell that out in so many terms, but that is why our upgrade scripts for postgis 1.5 are labeled -- postgis_upgrade_13_to_15.sql, postgis_upgrade_14_to_15.sql, postgis_upgrade_15_minor.sql.
We wouldn't need a postgis_upgrade_15_minor.sql if we never planned for people to run updates on a micro version.
comment:8 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Regina
I don't think it was insufficient spelled out, just me forgetting my head somewhere.
Now it should be fixed in 7066 (1.5) and 7067 (1.4)
Fixed in r7054
But what about 1.5 and 1.4?
A fix would change the sql interface which we are not supposed to do in micro-updates.
Should we just leave it?
Maybe put an updated function in the wiki?