Opened 8 months ago

Last modified 5 months ago

#5498 new defect

ERROR: function st_approxquantile(raster, double precision) is not unique

Reported by: strk Owned by: robe
Priority: medium Milestone: PostGIS 3.5.0
Component: raster Version: master
Keywords: Cc: Bborie Park

Description

Triggered by:

create extension postgis_raster cascade;
select st_approxquantile(NULL::raster, NULL::float8);

Tested to fail in 3.4.0, 3.3.3, 3.2.3, 3.1.6dev, 3.0.9dev

I cannot find a trace in the NEWS file about when that function was introduced but it seems to be very old (12 years ago): #935

It doesn't look like the function is even documented

Change History (3)

comment:1 by strk, 8 months ago

Cc: Bborie Park added

Bborie any idea ? ST_Quantile is tested under raster/test/regress/rt_quantile.sql and documented in https://postgis.net/docs/manual-dev/en/RT_ST_Quantile.html but ST_ApproximateQuantile is neither tested nor documented, but exists. Should it be dropped or documented/tested ?

comment:2 by strk, 8 months ago

Upon installing current master branch (3.5.0dev) there are 9 signatures of ST_ApproxQuantiles and two conflicting ones are:

-- Cannot be strict as "quantiles" can be NULL
CREATE OR REPLACE FUNCTION st_approxquantile(
  rast raster,
  sample_percent double precision,
  quantiles double precision[] DEFAULT NULL,
  OUT quantile double precision,
  OUT value double precision
)

And

CREATE OR REPLACE FUNCTION st_approxquantile(rast raster, quantile double precision)

The two functions even have a different return: the first one returns SETOF record, the second one returns a double.

comment:3 by robe, 5 months ago

Milestone: PostGIS 3.0.10PostGIS 3.5.0

I think we probably need to drop some of these definitions, but given no one else has complained, I suspect they aren't widely used. Presumably cause they aren't documented so no one knows about them.

I recall Bborie having created these to get speedier but less accurate calculations.

At anyrate the fix sounds like to drop overlapping sql signatures which qualifies as an api change, so we can't do this until 3.5.0 per our rules.

Note: See TracTickets for help on using tickets.