Re: Unsigned integer types - Mailing list pgsql-hackers

From Maciej Gajewski
Subject Re: Unsigned integer types
Date
Msg-id CAEcSYXJeo-nUHqFiWe=vXAtxXDQnU-0r7_V2cGhMT3w+5S8HBw@mail.gmail.com
Whole thread Raw
In response to Re: Unsigned integer types  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Unsigned integer types
Re: Unsigned integer types
Re: Unsigned integer types
List 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



pgsql-hackers by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: GRANT role_name TO role_name ON database_name
Next
From: Andres Freund
Date:
Subject: Re: pg_dump with postgis extension dumps rules separately