Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ecto support for range operators #10

Open
davydog187 opened this issue Nov 2, 2022 · 2 comments
Open

Add ecto support for range operators #10

davydog187 opened this issue Nov 2, 2022 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@davydog187
Copy link
Owner

Postgres ranges have convenient operators for doing set math on ranges. We can extend the Ecto DSL to provide convenience macros for working with these operators

e.g.

CREATE TABLE reservation (room int, during tsrange);
INSERT INTO reservation VALUES
    (1108, '[2010-01-01 14:30, 2010-01-01 15:30)');

-- Containment
SELECT int4range(10, 20) @> 3;

-- Overlaps
SELECT numrange(11.1, 22.2) && numrange(20.0, 30.0);

-- Extract the upper bound
SELECT upper(int8range(15, 25));

-- Compute the intersection
SELECT int4range(10, 20) * int4range(15, 25);

-- Is the range empty?
SELECT isempty(numrange(1, 5));

For the complete list, see the Postgres docs.

@davydog187 davydog187 added enhancement New feature or request help wanted Extra attention is needed labels Nov 2, 2022
@sloanelybutsurely
Copy link

@davydog187 do you have an idea of how you'd like to handle operators which exist for ranges within postgres but are not valid operators in elixir or are otherwise in use (e.g. @>, &&, -|-)?

postgres operator supported in elixir?
@>, <@
>>, <<
&<, >&
-|-
&&, +, *, - ✅ (i assume these are already translated by the Ecto query builder)

there are some unused operators which are maybe similar to the missing operators that could be used: |||, >>>, ~>, <->, etc.

Operators - Custom and overridden operators

@davydog187
Copy link
Owner Author

@sloanelybutsurely I haven't given it much thought, but I don't find any of these operators particularly readable. My preference would be to use atoms with clearer names rather than try to mimic the SQL syntax 1-1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants