From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | crocket <crockabiscuit(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Is there any plan to add unsigned integer types? |
Date: | 2011-09-26 14:02:04 |
Message-ID: | CAHyXU0wuRzTGvagZ=iK3QTWbVEC5MTj7V3cnffSVgr33wj00Fw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 26, 2011 at 5:41 AM, crocket <crockabiscuit(at)gmail(dot)com> wrote:
> MySQL already has unsigned INT type, and it has double the range of
> signed INT type.
> It's not just the bigger range that UINT type brings.
> If unsigned INT type exists, I wouldn't have to execute "create domain
> UINT" in every database.
>
> If "INT unsigned" and "SERIAL unsigned" exist, PostgreSQL would bring
> more convenience to users.
This comes up now and then. The problem is the benefit gained is not
really worth the pain. In today's 64 bit world, choosing a 64 bit int
nails the cases where you need the extra range and you have the
ability to use constraints (if necessary, through a domain) to enforce
correctness.
On the downside, you have to add a lot of casts, overloads, etc.
Figuring out the casting rules is non trivial and could lead to
surprising behaviors...inferring the type of 'unknown' strings is bad
enough as it is.
TBH, what I'd greatly prefer to see is to have domains be finished up
so that you don't have to carefully consider their use (for example,
you can't make arrays out of them). Then an unsigned int could simply
be:
create domain uint as bigint check (value >= 0);
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-26 14:04:10 | Re: contrib/sepgsql regression tests are a no-go |
Previous Message | Peter Geoghegan | 2011-09-26 13:53:49 | Re: Inlining comparators as a performance optimisation |