Re: Another question about Range types - Mailing list pgsql-general

From Mike Christensen
Subject Re: Another question about Range types
Date
Msg-id CABs1bs3zbu1CX3-n322KXv--nvPCLaUL2CQarSzSQ8jggBtjYA@mail.gmail.com
Whole thread Raw
In response to Another question about Range types  (Mike Christensen <mike@kitchenpc.com>)
Responses Re: Another question about Range types  ("Francisco Figueiredo Jr." <francisco.figueiredo.jr@gmail.com>)
List pgsql-general
Done.  Bug #1011216

On Fri, Aug 3, 2012 at 1:11 PM, Francisco Figueiredo Jr.
<francisco.figueiredo.jr@gmail.com> wrote:
>
> Regarding npgsql, range types have no direct mapping so they will be treated
> like strings. Sorry for that.
>
> I'll work to add support to it. Would you mind to fill a feature request
> about that on our feature requests project page? http://project.npgsql.org
>
> Thanks in advance.
>
> Em 03/08/2012 17:01, "Mike Christensen" <mike@kitchenpc.com> escreveu:
>>
>> There's another ongoing thread about range types, which was great
>> because I wasn't familiar with the feature (guess it's new in 9.2?).
>>
>> I run a recipe website and was looking for *exactly* this sort of
>> feature a few weeks ago when I was adding in support for ranges of
>> ingredients (such as "1-2tsp salt").  In the end, I implemented it
>> using two columns (QtyHigh and QtyLow).  In the salt example, QtyHigh
>> would be 2 and QtyLow would be 1.  I also have some CHECK constraints
>> to make sure high is always higher, and they're not the same, and not
>> negative or anything.
>>
>> Now, for 99% of the ingredients, QtyHigh would have a value and QtyLow
>> would just be null.  For example, "2tsp salt" would have a QtyHigh of
>> 2 and a QtyLow of null, which would indicate there is no range.
>>
>> I'm curious if I could combine these columns into one using a RANGE
>> type.  Obviously, if the column only stored ranges, it would be easy.
>> However, can a range also be one-dimensional?  Can I have a High value
>> and no low value?  Or would the recommended design be to have high/low
>> be the same?  Overall, would this scenario be an appropriate use case
>> for this RANGE type, since only some of the data are ranges?
>>
>> BONUS Question:
>>
>> How are RANGE types represented in Npgsql, or are they even supported yet?
>>
>> Mike
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general

pgsql-general by date:

Previous
From: Chris Angelico
Date:
Subject: Re: strategies for segregating client data when using PostgreSQL in a web app
Next
From: Rory Campbell-Lange
Date:
Subject: Re: strategies for segregating client data when using PostgreSQL in a web app