Re: Unsigned integer types

From: Maciej Gajewski <maciej(dot)gajewski0(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Jim Nasby <jim(at)nasby(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unsigned integer types
Date: 2013-05-29 08:33:44
Message-ID: CAEcSYXJeo-nUHqFiWe=vXAtxXDQnU-0r7_V2cGhMT3w+5S8HBw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I will implement it as an extension then.

My feeling is that PostgreSQL extensions tend to fall into obscurity.
As an ordinary user it took me really long time to find out that
interesting features are available in form of extensions; they are
certainly under-marketed. But this is a topic for separate discussion.

> You have not at all addressed the real problem with doing what you are asking for, the one that Tom Lane stated:

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

I'm sorry, I thought my proposal was clear.

I propose to not integrate the unsigned types into existing promotion
hierarchy, and behave just like gcc would with -Werror: require
explicit cast. Between them, the unsigned types would be automatically
converted up (uint2 > uint4 > uint8).

Maciek

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-05-29 10:31:09 Re: pg_dump with postgis extension dumps rules separately
Previous Message Albe Laurenz 2013-05-29 08:26:59 Re: GRANT role_name TO role_name ON database_name