Re: Extending range type operators to cope with elements

>
>
> >- @> contains range/element
> >- <@ element/range is contained by
>

I'm not a heavy user or range types, so I can't really judge how useful
> that is in practice, but it seems like a fairly natural extension of the
> existing operators. I mean, if I understand it correctly, the proposed
> behavior is equal to treating the element as a "collapsed range".
>

I used to give a talk on ranges and partitioning, prior to postgresql
getting native partitioning (see:
https://wiki.postgresql.org/images/1/1b/Ranges%2C_Partitioning_and_Limitations.pdf
)
In that talk, I mention the need for exactly these operators, specifically
for an extension called range_partitioning which had some logic for "If I
were to insert a row with this value, what partition would it end up in?"
which allowed for a subsequent COPY operation directly to that partition.
That logic essentially binary-searched a series of ranges, so it needed an
"elem <@ range" as well as << and >>.

Yes, constructing a collapsed range was the work-around I used in the
absence of real functions.

That extension has been replaced by real table partitioning and the planner
itself now does similar logic for partition pruning.

So yes, I've had a need for those operators in the past. What I don't know
is whether adding these functions will be worth the catalog clutter.