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
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 |