On May 29, 2013, at 10:48 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
If you do it, having uint1 (1 byte) would be nice as well.
There is a signed 1byte int on PGXN, FWIW:
http://pgxn.org/extension/tinyint
Best,
David
--
Sent via pgsql-hackers mailing list
If you do it, having uint1 (1 byte) would be nice as well.
There is a signed 1byte int on PGXN, FWIW:
http://pgxn.org/extension/tinyint
That's good, thanks for the pointer!
However, it is a signed tinyint (-128..127 range), not an unsigned one.
--
Fabien.
--
Sent via 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
On Wed, May 29, 2013 at 4:33 AM, Maciej Gajewski
maciej.gajews...@gmail.com wrote:
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
On 05/29/2013 11:33 AM, Maciej Gajewski wrote:
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
I agree that extensions are undermarketed. Although pgxn is a good step,
I could not find it from postgresql.org:-(
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
The reasons are: performance, storage and frustration.
I think the frustration comes from the fact that unsigned integers are
universally available, except in PostgreSQL. I work with a really
complex system, with many moving parts, and Postgres really is one of
the components that causes the
On 05/28/2013 05:17 AM, Maciej Gajewski wrote:
I'm afraid that implementing uints as and extension would introduce
some performance penalty (I may be wrong).
You are.
I'm also afraid that with
the extension I'd be left on my own maintaining it forever. While if
this could go into the core
On Tue, May 28, 2013 at 11:17:42AM +0200, Maciej Gajewski wrote:
2. INTEGER
I had to store a record with several uint32. I had to store an awful
lot of them; hundreds GB of data per day. Roughly half of the record
consists of uint32 fields.
Increasing the data type to bigint would mean that
On 5/28/13 4:07 PM, Bruce Momjian wrote:
On Tue, May 28, 2013 at 11:17:42AM +0200, Maciej Gajewski wrote:
2. INTEGER
I had to store a record with several uint32. I had to store an awful
lot of them; hundreds GB of data per day. Roughly half of the record
consists of uint32 fields.
Increasing
Maciej Gajewski wrote
I'm also afraid that with
the extension I'd be left on my own maintaining it forever. While if
this could go into the core product, it would live forever.
Clarification from the gallery: are we talking an extension or a custom
PostgreSQL build/fork?
If it is an extension
On Tue, May 28, 2013 at 05:57:41PM -0500, Jim Nasby wrote:
On 5/28/13 4:07 PM, Bruce Momjian wrote:
On Tue, May 28, 2013 at 11:17:42AM +0200, Maciej Gajewski wrote:
2. INTEGER
I had to store a record with several uint32. I had to store an awful
lot of them; hundreds GB of data per day.
On 05/28/2013 07:00 PM, Bruce Momjian wrote:
On Tue, May 28, 2013 at 05:57:41PM -0500, Jim Nasby wrote:
Did you try 'oid' as an unsigned int4?
Using an internal catalog type for user data seems like a horrible idea to me...
Uh, not sure if we can say oid is only an internal catalog type.
Hi all
I know this topic was discussed before, but there doesn't seem to be
any conclusion.
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
Maciej Gajewski wrote:
I know this topic was discussed before, but there doesn't seem to be
any conclusion.
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
Maciej Gajewski maciej.gajews...@gmail.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?
16 matches
Mail list logo