Skip site navigation (1) Skip section navigation (2)

Re: Unsigned int functions

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>, Postgresql <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unsigned int functions
Date: 2001-03-29 20:03:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> writes:
> > Question is: should I add these functions? Are we looking at too much
> > bloat, i.e. should I replace the (uint2,uint4) combinations with
> > (int4,uint2) and (int4,uint4)? Lots of combinations are possible, but I
> > do not have a good feel for the trade-offs. 
> My guess is that we ought to avoid bloating the system with
> cross-datatype functions.  I know there are some already for int2*int4
> and so forth, but I'd like to see those go away in favor of a smarter
> type promotion scheme --- ie, the parser should be able to figure out
> that it ought to do int2_var * uint4_var as
> 	uint4_mul(uint4(int2_var), uint4_var)
> A cross-datatype function ought to exist only if it can usefully do
> something different from an implicit promotion.

A larger question is whether unsigned types really add much to the
system vs. the bloat.  We already have unsigned int4 as oid.  Also,
unsigned doubles the space of the type, but if a value doesn't fit in
32k, what are the odds it will fit in 64k.  I am not sure unsigned
optimzations for space really are significant in SQL.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to


pgsql-hackers by date

Next:From: The Hermit HackerDate: 2001-03-29 20:21:58
Subject: RC2 schedualed for Tomorrow evening ...
Previous:From: Alfred PerlsteinDate: 2001-03-29 19:57:30
Subject: Re: [ADMIN] Re: Re: [PORTS] pgmonitor and Solaris

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group