Paul, do you know what's going on here? Why is extent(column) returning a box3d now?

Yes, there were renovations to extent calculation to try and return more exact results, but that required a hack type, which in turn required other messes. There's an issue here now:

http://code.google.com/p/postgis/issues/detail?id=149

Paul, I was trying to look into that issue (out of curiosity) but it seems the project is completely locked down? I get an error saying I don't have permissions to look, neither at the issue itself, not at the project home page (http://code.google.com/p/postgis/)

I don't know whether it is related to this issue, but I get this error (GeoServer 2.0 RC1, PostGIS 1.4.0 on PostgreSQL 8.3.7) when I try to issue a delete using WFS-T:

postData="<wfs:Transaction version=\"1.0.0\" service=\"WFS\"
xmlns:cnmca=\"http://www.meteoam.it/cnmca\"
xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\"
xmlns:wfs=\"http://www.opengis.net/wfs\">
<wfs:Delete typeName=\"cnmca:fenomeno\">
<ogc:Filter>
<ogc:PropertyIsBetween>
<ogc:PropertyName>t</ogc:PropertyName>
<ogc:LowerBoundary>
<ogc:Literal>2009-02-05T11:31:00</ogc:Literal>
</ogc:LowerBoundary>
<ogc:UpperBoundary>
<ogc:Literal>2009-02-05T11:33:00</ogc:Literal>
</ogc:UpperBoundary>
</ogc:PropertyIsBetween>
</ogc:Filter>
</wfs:Delete>
</wfs:Transaction>"

curl --basic --user "$auth" --proxy $http_proxy \
-H "Content-Type:text/xml;charset=UTF-8" \
--data "$postData" \
"$host"/wfs

Oddly, when I try a GetFeature with the same filter, it works as advertised:
postData="<Filter>
<PropertyIsBetween>
<PropertyName>t</PropertyName>
<LowerBoundary>
<Literal>2009-02-05T11:31:00</Literal>
</LowerBoundary>
<UpperBoundary>
<Literal>2009-02-05T11:33:00</Literal>
</UpperBoundary>
</PropertyIsBetween>
</Filter>"

curl --basic --user "$auth" --proxy $http_proxy \
-H "Content-Type:text/xml;charset=UTF-8" \
--data "$postData" \
"$host"/wfs?request=GetFeature\&typename=cnmca:fenomeno\&service=wfs\&version=1.1.0

I have made a few more tries, and the issue seems to boil down to an SQL function that is called with the wrong parameters.

The GeoServer-generated query is:
SELECT AsText(force_2d(Envelope(Extent("the_geom")))) FROM "public"."fenomeno" WHERE "t" BETWEEN '2007-02-05 12:31:00.0' AND '2010-02-05 12:33:00.0'

To which PostgreSQL replies:
<<
ERROR: function envelope(box3d_extent) does not exist
LINE 1: ...CT COUNT AS total FROM (SELECT AsText(force_2d(Envelope(E... ^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
>>

By the way, I have succesfully executed a similar query on a different configuration (PostgreSQL 8.3.7 with PostGIS 1.3.6)

Luca, I had a user on the GeoServer users list telling me GeoServer works fine with PG 1.4
At the same time I heard that change in the postgis extent function was to be reverted before the 1.4 final release. Are you using a final version?

I really need to install a 1.4 somewhere... bah, wish had more time...

Yes, I downloaded the 1.4.0 final (released on the 24th of July 2009) and did a soft upgrade of the database. Previously I had the 1.3.6 installed... and never installed a trunk version.

Anyway, this is what I've found in postgis.sql.in.c related to extent:
..
– Deprecation in 1.2.3
CREATE AGGREGATE Extent(
sfunc = ST_combine_bbox,
basetype = geometry,
stype = box3d_extent
);
....
– Deprecation in 1.2.3
CREATE AGGREGATE Extent3d(
sfunc = combine_bbox,
basetype = geometry,
stype = box3d
);
...

I will be happy to help you in this, if you need more info or some testing done, just ask.

Well, you could definitely save me some research if you found a way to get the same result as before with the new function signatures. If that way could work with the older databases, so that I don't have to setup a translation table that takes into account both pg version and the function to be encoded, well, that would be great (one less maintenance headache).

After all, in PostGIS 1.3.6 there IS different function signature:
– Deprecation in 1.2.3
CREATE AGGREGATE Extent(
sfunc = ST_combine_bbox,
basetype = geometry,
stype = box2d
);

(in 1.4.0 the stype has changed to box3d_extent)... but how to get the same result with both PostGIS versions ?

I don't know, that the "research" I was talking about above.
If there is no way we'll be forced to setup a function translation matrix that takes as input what we want to do and the postgis version at hand and returns the proper function name.
Which is no small changes and makes testing hard (testing builds against two different releases of postgis? that's simply not going to happen with the resources we have at hand right now).

Forcing the result of extent to be a "geometry" type may do the trick:
SELECT AsText(force_2d(Envelope(ST_Geometry(Extent("the_geom"))))) FROM "public"."fenomeno" WHERE "t" BETWEEN '2007-02-05 12:31:00.0' AND '2010-02-05 12:33:00.0';

This works on both PostGIS 1.3.6 and 1.4.0.

More information on this issue on the PostGIS site

Could I do more to help ?

ST_Geometry as a function is not declared in older versions of PostGIS (< 1.2 I think)... wondering if there is any alias that would work with older pg versions as well

After pulling hairs for a good hour trying to get the postgis 1.4 installed in a VirtualBox VM be visible and usable from my desktop I... could not reproduce the issue.
Everything works just fine.

Here is what I have:

gttest=# select postgis_version();
            postgis_version            
---------------------------------------
 1.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
(1 riga)

gttest=# \d states
                                  Tabella "public.states"
  Colonna   |         Tipo          |                     Modificatori                     
------------+-----------------------+------------------------------------------------------
 gid        | integer               | not null default nextval('states_gid_seq'::regclass)
 state_name | character varying(25) | 
 state_fips | character varying(2)  | 
 sub_region | character varying(7)  | 
 state_abbr | character varying(2)  | 
 land_km    | numeric               | 
 water_km   | numeric               | 
 persons    | numeric               | 
 families   | numeric               | 
 houshold   | numeric               | 
 male       | numeric               | 
 female     | numeric               | 
 workers    | numeric               | 
 drvalone   | numeric               | 
 carpool    | numeric               | 
 pubtrans   | numeric               | 
 employed   | numeric               | 
 unemploy   | numeric               | 
 service    | numeric               | 
 manual     | numeric               | 
 p_male     | numeric               | 
 p_female   | numeric               | 
 samp_pop   | numeric               | 
 the_geom   | geometry              | 
Indici:
    "states_pkey" PRIMARY KEY, btree (gid)
    "states_the_geom_gist" gist (the_geom)
Vincoli di controllo:
    "enforce_dims_the_geom" CHECK (st_ndims(the_geom) = 2)
    "enforce_geotype_the_geom" CHECK (geometrytype(the_geom) = 'MULTIPOLYGON'::text OR the_geom IS NULL)
    "enforce_srid_the_geom" CHECK (st_srid(the_geom) = 4326)

gttest=# SELECT AsText(force_2d(Envelope(Extent("the_geom")))) FROM states;
                                                                                          astext                                                                                           
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POLYGON((-124.731422424316 24.9559669494629,-124.731422424316 49.3717384338379,-66.9698486328125 49.3717384338379,-66.9698486328125 24.9559669494629,-124.731422424316 24.9559669494629))
(1 riga)

My guess is that you have some database that has been upgraded from earlier, beta 1.4 postgis versions?

I guess you're right Andrea: I've created a database anew with PostGIS 1.4.0 on same data and it worked... no idea what went wrong upgrading from PostGIS 13.6 to 1.4.0.
As far as I am concerned, the issue can be closed.