On Tue, Aug 20, 2019 at 10:33 PM Jeff Davis <pg...@j-davis.com> wrote: > > Is there any historical discussion around > > typemods on range types? > > I did find a few references:
Thanks for looking those up! It's very interesting to see some of the original discussion around range types. Btw this is true of so much, isn't it?: > It's more a property of the > column than the type. Sometimes I think about having a maybe<T> type instead of null/not null. SQL nulls are already very "monadic" I think but nullability doesn't travel. I feel like someone ought to write a paper about that, but I don't know of any. This is tantalizingly close (and a fun read) but really about something else: https://www.researchgate.net/publication/266657590_Incomplete_data_what_went_wrong_and_how_to_fix_it Since you're getting into Rust maybe you can update the wiki page mentioned in those threads about refactoring the type system. :-) Anyway sorry for the digression. . . . > So, I wouldn't spend a lot of time on typmod for multiranges. Okay, thanks! There is plenty else to do. I think I'm already supporting it as much as range types do. Btw I have working multirange_{send,recv,in,out} now, and I automatically create a multirange type and its array type when someone creates a new range type. I have a decent start on passing tests and no compiler warnings. I also have a start on anymultirange and anyrangearray. (I think I need the latter to support a range-like constructor function, so you can say `int4multirange(int4range(1,4), int4range(8,10))`.) I want to get the any* types done and improve the test coverage, and then I'll probably be ready to share a patch. Here are a couple other questions: - Does anyone have advice for the typanalyze function? I feel pretty out of my depth there (although I haven't looked into typanalyze stuff very deeply yet). I can probably get some inspiration from range_typanalyze and array_typanalyze, but those are both quite detailed (their statistics functions that is). - What should a multirange do if you give it an empty range? I'm thinking it should just ignore it, but then `'{}'::int4multirange = '{empty}'::int4multirange`. Does that seem okay? (It does to me actually, if we think of `empty` as the additive identity. Similarly mr + empty = mr. - What should a multirange do if you give it a null, like `int4multirange(int4range(1,4), null)`. I'm thinking it should be null, just like mr + null = null. Right? Thanks! Paul
