From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Ryan Bradetich" <rbradetich(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] Unsigned integer support. |
Date: | 2008-07-25 10:57:34 |
Message-ID: | 87sktykz8h.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
> My plans for the example above would be:
>
> 1. SELECT 1500000000 + 1500000000 --> Throws overflow error.
> 2. SELECT 1500000000::uint4 + 1500000000 --> Returns 3000000000::uint4.
I think that wouldn't actually work. Postgres's parser immediately assigns a
type to the bare unquoted integral constant so it would end up with a int4
type. Then when it has to pick an operator for uint4+int4 it wouldn't be able
to cast the int4 to uint4 because there would be no implicit cast.
You could make it work by having a uint4+int4 operator which returns uint4 but
then you're going to need a *lot* of operators....
One other idea that's been mentioned before is treating integral constants
like 150000 as type "unknown" like the quoted '150000' constant is. That way
the parser would see uint4+unknown and could pick the uint4 operator. But that
would be a pretty massive semantics change.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-07-25 12:14:45 | Re: [RFC] Unsigned integer support. |
Previous Message | Stephen Frost | 2008-07-25 09:51:33 | Re: Column level privileges was:(Re: Extending grant insert on tables to sequences) |