Re: [HACKERS] anyelement -> anyrange

2016-08-19 Thread Corey Huinker
On Fri, Aug 19, 2016 at 11:40 AM, Jim Nasby wrote: > On 8/18/16 6:02 PM, Corey Huinker wrote: > >> I'd be happy to roll your code into the extension, and make it marked >> more stable. >> > > Yeah, I've been meaning to look at submitting a pull request; hopefully > will

Re: [HACKERS] anyelement -> anyrange

2016-08-19 Thread Jim Nasby
On 8/18/16 6:02 PM, Corey Huinker wrote: I'd be happy to roll your code into the extension, and make it marked more stable. Yeah, I've been meaning to look at submitting a pull request; hopefully will get to it today. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in

Re: [HACKERS] anyelement -> anyrange

2016-08-18 Thread Corey Huinker
I'd be happy to roll your code into the extension, and make it marked more stable. On Thu, Aug 18, 2016 at 2:49 PM, Jim Nasby wrote: > On 8/18/16 1:06 PM, Corey Huinker wrote: > >> You might also find some gleanable gems in: >>

Re: [HACKERS] anyelement -> anyrange

2016-08-18 Thread David E. Wheeler
On Aug 18, 2016, at 11:49 AM, Jim Nasby wrote: > Well crap, I searched for range stuff on PGXN before creating > http://pgxn.org/dist/range_tools/ and the only thing that came up was your > range_partitioning stuff, which AFAICT is unrelated. >

Re: [HACKERS] anyelement -> anyrange

2016-08-18 Thread Jim Nasby
On 8/18/16 1:06 PM, Corey Huinker wrote: You might also find some gleanable gems in: https://github.com/moat/range_type_functions/blob/master/doc/range_type_functions.md Well crap, I searched for range stuff on PGXN before creating http://pgxn.org/dist/range_tools/ and the only thing that

Re: [HACKERS] anyelement -> anyrange

2016-08-18 Thread Corey Huinker
On Tue, Aug 16, 2016 at 9:29 PM, Tom Lane wrote: > Jim Nasby writes: > > I can't think of any reason you'd want two different range types on a > > single element type. > > We would not have built it that way if there were not clear use-cases. > An

Re: [HACKERS] anyelement -> anyrange

2016-08-16 Thread Tom Lane
Jim Nasby writes: > I can't think of any reason you'd want two different range types on a > single element type. We would not have built it that way if there were not clear use-cases. An easy example is you might want both a continuous timestamp range and one that is

Re: [HACKERS] anyelement -> anyrange

2016-08-16 Thread Jim Nasby
On 8/16/16 6:56 PM, David G. Johnston wrote: On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby >wrote: On 8/15/16 10:12 PM, Tom Lane wrote: Jim Nasby writes: Any reason why we can create a

Re: [HACKERS] anyelement -> anyrange

2016-08-16 Thread David G. Johnston
On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby wrote: > On 8/15/16 10:12 PM, Tom Lane wrote: > >> Jim Nasby writes: >> >>> Any reason why we can create a function that accepts anyelement and >>> returns anyarray, but can't do the same with

Re: [HACKERS] anyelement -> anyrange

2016-08-16 Thread Jim Nasby
On 8/15/16 10:12 PM, Tom Lane wrote: Jim Nasby writes: Any reason why we can create a function that accepts anyelement and returns anyarray, but can't do the same with anyrange? Because there can be more than one range type over the same element type, so we couldn't

Re: [HACKERS] anyelement -> anyrange

2016-08-15 Thread Tom Lane
Jim Nasby writes: > Any reason why we can create a function that accepts anyelement and > returns anyarray, but can't do the same with anyrange? Because there can be more than one range type over the same element type, so we couldn't deduce which one should be used for