{"action":"created","issue":{"url":"https://api.github.com/repos/npgsql/npgsql/issues/1943","repository_url":"https://api.github.com/repos/npgsql/npgsql","labels_url":"https://api.github.com/repos/npgsql/npgsql/issues/1943/labels{/name}","comments_url":"https://api.github.com/repos/npgsql/npgsql/issues/1943/comments","events_url":"https://api.github.com/repos/npgsql/npgsql/issues/1943/events","html_url":"https://github.com/npgsql/npgsql/issues/1943","id":324991136,"node_id":"MDU6SXNzdWUzMjQ5OTExMzY=","number":1943,"title":"Determining if NpgsqlRange<T> is implicitly empty","user":{"login":"austindrenski","id":21338699,"node_id":"MDQ6VXNlcjIxMzM4Njk5","avatar_url":"https://avatars3.githubusercontent.com/u/21338699?v=4","gravatar_id":"","url":"https://api.github.com/users/austindrenski","html_url":"https://github.com/austindrenski","followers_url":"https://api.github.com/users/austindrenski/followers","following_url":"https://api.github.com/users/austindrenski/following{/other_user}","gists_url":"https://api.github.com/users/austindrenski/gists{/gist_id}","starred_url":"https://api.github.com/users/austindrenski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/austindrenski/subscriptions","organizations_url":"https://api.github.com/users/austindrenski/orgs","repos_url":"https://api.github.com/users/austindrenski/repos","events_url":"https://api.github.com/users/austindrenski/events{/privacy}","received_events_url":"https://api.github.com/users/austindrenski/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2018-05-21T17:09:04Z","updated_at":"2018-06-03T20:50:11Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Moved from: https://github.com/npgsql/npgsql/pull/1939#discussion_r189436481\r\n\r\n```c#\r\n// TODO: We need to check if the bounds are implicitly empty. E.g. '(1,1)' or '(0,0]'.\r\n```\r\n\r\n@roji:\r\n> Very true. We could implement this for some of the commonly-used range types (i.e. the ones that come built-in in PostgreSQL), although this can be left for later.\r\n\r\n@austindrenski:\r\n> I'm planning to handle this more thoroughly in a separate PR down the road.\r\n>\r\n> Basically, I think we need to incorporate the concept of range types being [continuous/discrete](https://www.postgresql.org/docs/current/static/rangetypes.html#RANGETYPES-DISCRETE) in order to handle this properly.\r\n>\r\n> I'm still thinking through the design, but one approach would be to [follow PostgreSQL](https://www.postgresql.org/docs/current/static/rangetypes.html#RANGETYPES-DEFINING) and have the user provide canonical functions, which would then allow us to increment/decrement for checks like this. I think the trick here would be to provide these hooks while guarding against obvious performance pitfalls.\r\n\r\n@roji:\r\n> OK, please open a separate issue for discussing this (you can copy-paste my comments below there).\r\n>\r\n> Unless I'm mistaken, it's possible to identify discrete vs. continuous ranges in PostgreSQL by checking for the existence of a cannonicalization function ([`pg_range.rngcanonical`](https://www.postgresql.org/docs/current/static/catalog-pg-range.html)), as [described in the docs](https://www.postgresql.org/docs/current/static/rangetypes.html#RANGETYPES-DISCRETE).\r\n>\r\n> The problem is that `NpgsqlRange<T>` isn't actually attached to any actual PostgreSQL database, and I think it's good to keep it that way. I think that a complex mechanism for loading discreteness from PostgreSQL would be a big overkill and of very little value (in theory two databases could also have the same range type defined but with different discreteness; but we really shouldn't go this far).\r\n>\r\n> So it seems to me this is best handled by hardcoding the discreteness in code, which would probably cover at least 99% of the use cases.\r\n"},"comment":{"url":"https://api.github.com/repos/npgsql/npgsql/issues/comments/394190358","html_url":"https://github.com/npgsql/npgsql/issues/1943#issuecomment-394190358","issue_url":"https://api.github.com/repos/npgsql/npgsql/issues/1943","id":394190358,"node_id":"MDEyOklzc3VlQ29tbWVudDM5NDE5MDM1OA==","user":{"login":"austindrenski","id":21338699,"node_id":"MDQ6VXNlcjIxMzM4Njk5","avatar_url":"https://avatars3.githubusercontent.com/u/21338699?v=4","gravatar_id":"","url":"https://api.github.com/users/austindrenski","html_url":"https://github.com/austindrenski","followers_url":"https://api.github.com/users/austindrenski/followers","following_url":"https://api.github.com/users/austindrenski/following{/other_user}","gists_url":"https://api.github.com/users/austindrenski/gists{/gist_id}","starred_url":"https://api.github.com/users/austindrenski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/austindrenski/subscriptions","organizations_url":"https://api.github.com/users/austindrenski/orgs","repos_url":"https://api.github.com/users/austindrenski/repos","events_url":"https://api.github.com/users/austindrenski/events{/privacy}","received_events_url":"https://api.github.com/users/austindrenski/received_events","type":"User","site_admin":false},"created_at":"2018-06-03T20:50:11Z","updated_at":"2018-06-03T20:50:11Z","author_association":"CONTRIBUTOR","body":"I've opened #1974 to update `NpgsqlRange<T>` to use `ReadOnlySpan<char>` per some pre-`4.0.0` [discussion](https://github.com/npgsql/npgsql/pull/1939#pullrequestreview-121308396). \r\n\r\n@Brar I've included your unit test as `Roundtrip_canonicalization_causes_issues`. The condition is flipped such that passing means the issue exists."}}
{"actor":{"display_login":"austindrenski"}}