database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-30 21:42:05 +03:00
Code Activity

Fix "element <@ range" cost estimation.

Browse Source 
The statistics-based cost estimation patch for range types broke that, by
incorrectly assuming that the left operand of all range oeprators is a
range. That lead to a "type x is not a range type" error. Because it took so
long for anyone to notice, add a regression test for that case.

We still don't do proper statistics-based cost estimation for that, so you
just get a default constant estimate. We should look into implementing that,
but this patch at least fixes the regression.

Spotted by Tom Lane, when testing query from Josh Berkus.
This commit is contained in:
Heikki Linnakangas
2013-03-21 11:15:45 +02:00
parent f8348ea32e
commit f897c4744f
3 changed files with 24 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/backend/utils/adt/rangetypes_selfuncs.c
View File

@ -154,8 +154,6 @@ rangesel(PG_FUNCTION_ARGS)
}
}
typcache = range_get_typcache(fcinfo, vardata.vartype);
/*
* OK, there's a Var and a Const we're dealing with here. We need the
* Const to be of same range type as the column, else we can't do anything
@ -169,6 +167,8 @@ rangesel(PG_FUNCTION_ARGS)
*/
if (operator == OID_RANGE_CONTAINS_ELEM_OP)
{
typcache = range_get_typcache(fcinfo, vardata.vartype);
if (((Const *) other)->consttype == typcache->rngelemtype->type_id)
{
RangeBound lower, upper;
@ -185,6 +185,8 @@ rangesel(PG_FUNCTION_ARGS)
}
else
{
typcache = range_get_typcache(fcinfo, ((Const *) other)->consttype);
if (((Const *) other)->consttype == vardata.vartype)
constrange = DatumGetRangeType(((Const *) other)->constvalue);
}