Opened 13 years ago

Closed 12 years ago

Last modified 8 years ago

#877 closed defect (fixed)

st_estimated_extent returns error on empty table

Reported by: martins Owned by: pramsey
Priority: high Milestone: PostGIS 1.5.4
Component: postgis Version: 1.5.X
Keywords: history Cc:


To reproduce:

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 strk, 13 years ago


See also #510

I'd also like to see that message reworded…

comment:2 by mcayland, 13 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 strk, 13 years ago

That'd be a NULL.

comment:4 by strk, 13 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 robe, 13 years ago

Milestone: PostGIS 1.5.3PostGIS 1.5.4

comment:6 by martins, 12 years ago

Could this be fixed any time soon? We really need this functionality.

comment:7 by strk, 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 strk, 12 years ago

Owner: changed from pramsey to strk
Status: newassigned

Funded! I'm on it…

comment:9 by strk, 12 years ago

Keywords: history added

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 robe, 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 strk, 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 strk, 12 years ago

r8320 documents it in 1.5 branch (r8321 in trunk)

I found inspiration in ST_Extent, which changed return type in a given version.

Since we're discussing about boxes: this function returns box2d, ST_Extent returned box2d once and now returns box3d_extent, ST_3dExtent returns box3d.

comment:13 by strk, 12 years ago

Resolution: fixed
Status: assignedclosed

comment:14 by pramsey, 12 years ago

Resolution: fixed
Status: closedreopened

Something deeply wrong in this fix on OSX, will have to examine… fortunately the ticket regression picked it up.

comment:15 by pramsey, 12 years ago

Owner: changed from strk to pramsey
Status: reopenednew

comment:16 by pramsey, 12 years ago

Resolution: fixed
Status: newclosed

Fixed the OSX regression in 1.5 at r8985

comment:17 by strk, 8 years ago

This change regressed in 2.0.0, see #3396

Note: See TracTickets for help on using tickets.