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 get to it today.
>
>
No ru
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
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:
>> https://github.com/moat/range_type_functions/blob/master/doc
>> /ran
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.
> http://pgxn.org/dist/range_type_functions/still d
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 came
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 easy example is you might want both a continuous
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 quantized to hour boundaries
On 8/16/16 6:56 PM, David G. Johnston wrote:
On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby mailto:jim.na...@bluetreble.com>>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
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 anyrange?
>>>
>>
>> Because there can be more than one range
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 deduce which one should be
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 anyrange.
The other direc
Any reason why we can create a function that accepts anyelement and
returns anyarray, but can't do the same with anyrange? Could we attempt
to match each range subtype looking for a match?
create function range__create(anyelement,anyelement,text = '[]') RETURNS
anyrange LANGUAGE plpgsql AS $bo
12 matches
Mail list logo
