Re: pg_stats and range statistics

From: "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru>, Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_stats and range statistics
Date: 2023-03-20 19:27:37
Message-ID: CAM-w4HPNsCOjYBLjHhRa0U54sTZ1h+P0Q7+3ruqWHYvMyGm0tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 22 Jan 2023 at 18:22, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> I wonder if we have other functions doing something similar, i.e.
> accepting a polymorphic type and then imposing additional restrictions
> on it.

Meh, there's things like array comparison functions that require both
arguments to be the same kind of arrays. And array_agg that requires
the elements to be the same type as the state array (ie, same type as
the first element). Not sure there are any taking just one specific
type though.

> > Shouldn't this add some sql tests ?
>
> Yeah, I guess we should have a couple tests calling these functions on
> different range arrays.
>
> This reminds me lower()/upper() have some extra rules about handling
> empty ranges / infinite boundaries etc. These functions should behave
> consistently (as if we called lower() in a loop) and I'm pretty sure
> that's not the current state.

Are we still waiting on these two items? Egor, do you think you'll
have a chance to work it for this month?

--
Gregory Stark
As Commitfest Manager

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark (as CFM) 2023-03-20 19:30:41 Re: [PATCH] Add initial xid/mxid/mxoff to initdb
Previous Message Andres Freund 2023-03-20 19:16:39 Re: meson documentation build open issues