Strange behaviors with ranges

From: Jean-Christophe Boggio <postgresql(at)thefreecat(dot)org>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Strange behaviors with ranges
Date: 2024-08-27 17:29:16
Message-ID: 77691006-45f1-4ef9-bc1b-2eecd44f7d0d@thefreecat.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,

I have 2 very confusing behaviors when using ranges.

It all started with this query:

    WITH rangespaliers AS (
        SELECT numrange( qtep1+1   , qtep2,  '[]') AS rangep FROM
paliers JOIN tmp_limitcontrats USING(idcontrat)
--        SELECT numrange( qtep1+1   , qtep2,  '[]') AS rangep FROM
paliers WHERE idcontrat=1003
    )
    ,rangespaliers2 AS (
        select *
        FROM rangespaliers
        WHERE rangep <> NUMRANGE(NULL, NULL) -- ERROR IS HERE
    )
    select * from rangespaliers2;

When I run this query, I get the error "Range lower bound must be less
than or equal to range upper bound".

(a) If I comment out the line marked "ERROR IS HERE", I don't have an
error (but I'm missing the filter of course).

(b) Also, if I uncomment line 3 and comment out line 2, I get the
correct behavior. Very strange thing is that tmp_limitcontrats has only
one row which contains "idcontrat=1003".

Now, in that table "paliers", the line for idcontrat=1003 has value NULL
for both qtep1 and qtep2. So the final behavior should be an empty
result set.

You can reproduce the problem using the attached file:

CREATE TABLE paliers (
    idpalier integer NOT NULL,
    idcontrat integer NOT NULL,
    isdefault boolean NOT NULL,
    name character varying(30),
    qtep1 integer,
    qtep2 integer,
    qtep3 integer,
    qtep4 integer,
    qtep5 integer,
    qtep6 integer,
    qtep7 integer,
    qtep8 integer,
    qtep9 integer,
    qtep10 integer,
    qpp1 double precision,
    qpp2 double precision,
    qpp3 double precision,
    qpp4 double precision,
    qpp5 double precision,
    qpp6 double precision,
    qpp7 double precision,
    qpp8 double precision,
    qpp9 double precision,
    qpp10 double precision,
    idpalier_clonedfrom integer,
    assessonamounts boolean DEFAULT false,
    amountp1 numeric(15,2),
    amountp2 numeric(15,2),
    amountp3 numeric(15,2),
    amountp4 numeric(15,2),
    amountp5 numeric(15,2),
    amountp6 numeric(15,2),
    amountp7 numeric(15,2),
    amountp8 numeric(15,2),
    amountp9 numeric(15,2),
    tauxmini numeric(5,2)
);

copy
paliers(idpalier,idcontrat,isdefault,name,qtep1,qtep2,qtep3,qtep4,qtep5,qtep6,qtep7,qtep8,qtep9,qtep10,qpp1,qpp2,qpp3,qpp4,qpp5,qpp6,qpp7,qpp8,qpp9,qpp10,idpalier_clonedfrom,assessonamounts,amountp1,amountp2,amountp3,amountp4,amountp5,amountp6,amountp7,amountp8,amountp9,tauxmini)
from '/tmp/paliers.csv'
delimiter ','
csv header;

DROP TABLE IF EXISTS tmp_limitcontrats;
CREATE TABLE tmp_limitcontrats AS
    SELECT 1003 AS idcontrat;

WITH rangespaliers AS (
  SELECT numrange(qtep1+1,qtep2) as rangep FROM paliers JOIN
tmp_limitcontrats USING(idcontrat)
)
, rangespaliers2 AS (
  SELECT rangep, numrange(null,null)
  FROM rangespaliers
  WHERE rangep <> NUMRANGE(null,null)
)
select * from rangespaliers2;

This fails on PG 16.4 and 15.7

Thanks a lot for your enlightenment.

Attachment Content-Type Size
paliers.csv text/csv 46.9 KB

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2024-08-27 17:37:17 Re: Strange behaviors with ranges
Previous Message Tom Lane 2024-08-27 16:15:41 Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.