From: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SQL:2011 application time |
Date: | 2024-01-08 18:54:13 |
Message-ID: | d5b6527c-7386-4756-a633-4fc90622aa4e@illuminatedcomputing.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/8/24 06:54, jian he wrote:
> On Fri, Jan 5, 2024 at 1:06 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> range_intersect returns the intersection of two ranges.
> I think here we are doing the opposite.
> names the main SQL function "range_not_intersect" and the internal
> function as "range_not_intersect_internal" should be fine.
> so people don't need to understand the meaning of "portion".
Thank you for helping me figure out a name here! I realize that can be a bike-sheddy kind of
discussion, so let me share some of my principles.
Range and multirange are highly mathematically "pure", and that's something I value in them. It
makes them more general-purpose, less encumbered by edge cases, easier to combine, and easier to
reason about. Preserving that close connection to math is a big goal.
What I've called `without_portion` is (like) a closed form of minus (hence `(at)-` for the operator).
Minus isn't closed under everything (e.g. ranges), so `without_portion` adds arrays---much as to
close subtraction we add negative numbers and to close division we add rationals). We get the same
effect from multiranges, but that only buys us range support. It would be awesome to support
arbitrary types: ranges, multiranges, mdranges, boxes, polygons, inets, etc., so I think an array is
the way to go here. And then each array element is a "leftover". What do we call a closed form of
minus that returns arrays?
Using "not" suggests a function that returns true/false, but `(at)-` returns an array of things. So
instead of "not" let's consider "complement". I think that's what you're expressing re intersection.
But `(at)-` is not the same as the complement of intersection. For one thing, `(at)-` is not commutative.
`old_range @- target_portion` is not the same as `target_portion @- old_range`. But
`complement(old_range * target_portion)` *is* the same as `complement(target_portion * old_range)`.
Or from another angle: it's true that `old_range @- target_portion = old_range @- (old_range *
target_portion)`, but the intersection isn't "doing" anything here. It's true that intersection and
minus both "reduce" what you put in, but minus is more accurate.
So I think we want a name that captures that idea of "minus". Both "not" and "intersection" are
misleading IMO.
Of course "minus" is already taken (and you wouldn't expect it to return arrays anyway), which is
why I'm thinking about names like "without" or "except". Or maybe "multi-minus". I still think
"without portion" is the closest to capturing everything above (and avoids ambiguity with other SQL
operations). And the "portion" ties the operator to `FOR PORTION OF`, which is its purpose. But I
wouldn't be surprised if there were something better.
Yours,
--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2024-01-08 19:36:34 | Re: Emitting JSON to file using COPY TO |
Previous Message | Dean Rasheed | 2024-01-08 18:43:14 | Re: psql JSON output format |