Opened 12 years ago
Closed 11 years ago
Last modified 7 years ago
#877 closed defect (fixed)
st_estimated_extent returns error on empty table
|Reported by:||martins||Owned by:||pramsey|
create table t(gid serial); select addgeometrycolumn('t','g',4326,'GEOMETRY',2); vacuum analyze t; select st_estimated_extent('t','g');
ERROR: LWGEOM_estimated_extent: couldn't locate table within current schema
This is especially annoying for us, because we must execute estimated_extent inside a transaction.
Could the function be changed to return NULL instead of an error in this case?
Change History (17)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
I think the correct behaviour should be to mimic what "SELECT ST_Extent(foo) FROM table" returns on an empty table, and reduce the message to a WARNING.
comment:3 by , 12 years ago
That'd be a NULL.
comment:4 by , 12 years ago
Note that with current trunk the error message is this: ERROR: LWGEOM_estimated_extent: no statistics for "(current_schema)"."t"."g" (empty table ? did you run ANALYZE ?)
The condition is the same when the table is NOT empty but you didn't run analyze yet. Do we want to always return NULL, or try to tell the two cases apart ?
comment:5 by , 12 years ago
|Milestone:||PostGIS 1.5.3 → PostGIS 1.5.4|
comment:6 by , 12 years ago
Could this be fixed any time soon? We really need this functionality.
comment:7 by , 12 years ago
The quickest would be producing a patch and attaching to this ticket, or paying someone to do that for you. Shouldn't take more than a couple of hours.
comment:8 by , 12 years ago
|Status:||new → assigned|
Funded! I'm on it…
comment:9 by , 12 years ago
Fixed by r8319 in trunk and r8317 in 1.7 branch.
Documentation would need to be tweaked to reflect the semantic change. Not sure which expressions to use there. Robe ? Speaking of which, I've seen we advertise "VACUUM ANALYZE" as being the command gathering the statistics while "ANALYZE" is enough (and tested now within regress/ticket.sql)
comment:10 by , 12 years ago
you know you could update these things yourself. I guess I'd much rather have people run too much than too little as I don't want to hear their problems when they deleted or updated records. I think nowadays running vacuum analyze is just as fast because with the new changes in freespace map I forget which version — 8.4 or 9.0 — PostgreSQL is smart enough to know when a VACUUM is not necessary. So better to ere on the side of too much than too little.
I didn't know we had a 1.7 branch of PostGIS. When did this come about and why did no one inform me
comment:11 by , 12 years ago
Oops, it was 1.5 of course. Ok with keeping "vaccum analyze". About noticing the difference introduced (NULL instead of exception) I can surely do that myself. Was just asking about a tip for where to look about properly encoding the version-dependent change (some other function that has an example of which docbook tags to use for that?)
comment:12 by , 12 years ago
comment:13 by , 11 years ago
|Status:||assigned → closed|
comment:14 by , 11 years ago
|Status:||closed → reopened|
Something deeply wrong in this fix on OSX, will have to examine… fortunately the ticket regression picked it up.
comment:15 by , 11 years ago
|Status:||reopened → new|
comment:16 by , 11 years ago
|Status:||new → closed|
Fixed the OSX regression in 1.5 at r8985
comment:17 by , 7 years ago
This change regressed in 2.0.0, see #3396
See also #510
I'd also like to see that message reworded…