Re: Unsigned integer types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Maciej Gajewski <maciej(dot)gajewski0(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unsigned integer types
Date: 2013-05-27 14:16:12
Message-ID: 10633.1369664172@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Maciej Gajewski <maciej(dot)gajewski0(at)gmail(dot)com> writes:
> The lack of unsigned integer types is one of the biggest sources of
> grief in my daily work with pgsql.
> Before I go and start hacking, I'd like to discuss few points:
> 1. Is there a strong objection against merging this kind of patch?

Basically, there is zero chance this will happen unless you can find
a way of fitting them into the numeric promotion hierarchy that doesn't
break a lot of existing applications. We have looked at this more than
once, if memory serves, and failed to come up with a workable design
that didn't seem to violate the POLA.

> 2. How/if should the behaviour of numeric literals change?

> The minimalistic solution is: it shouldn't, literals should be assumed
> signed by default. More complex solution could involve using C-style
> suffix ('123456u').

Well, if you don't do that, there is no need for you to merge anything:
you can build unsigned types as an external extension if they aren't
affecting the core parser's behavior. As long as it's external, you
don't need to satisfy anybody else's idea of what reasonable behavior
is ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2013-05-27 14:23:59 Re: PostgreSQL Process memory architecture
Previous Message Albe Laurenz 2013-05-27 13:49:06 Re: Unsigned integer types