Hello Greg,
On Fri, Jul 25, 2008 at 3:57 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> 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....
This was my plan. I performed some testing last night to verify that
bare literals
are considered plain integers and would not be implicitly casted to a
different type
(i.e. smallint or bigint). I am seeing three operators for most operations:
1. uint4 -> uint4 = uint4
2. int4 -> uint4 = uint4
3. uint4 -> int4 = uint4
Is there something I need to watch out for when adding this number of
operators (i.e.
performance impact, etc)? Some tests I should be running to measure the impact
of adding these 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.
This would require changes to the core PostgreSQL code correct? My
goal for this
type was to have it as an external project on PgFoundry since there
does not appear
to be much demand for it and unsigned types are not specified in the
SQL standard.
If the community decides this support would be better in core
PostgreSQL code, then
I am willing to help with that work, but I will need a significant
amount of guidance :)
With my limited knowledge, the best (and easiest) path seems to take
advantage of
the extensible type system in PostgreSQL and support unsigned integers as a
PgFoundry project.
Thanks for your review and comments!
- Ryan
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
