Thread

  1. Re: Unsigned int functions

    Adriaan Joubert <a.joubert@albourne.com> — 2001-03-30T05:36:42Z

    Bruce Momjian wrote:
    > 
    > > Adriaan Joubert <a.joubert@albourne.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.
    
    A fair question. As I said, I only implemented them to simplify porting
    applications between database systems. Personally I think it is good to
    support types that make porting easier.
    
    On the other hand the arguments about bloat are strong. It seems to me
    that all cross-datatype functions should be removed, to reduce the
    number of functions for the unsigned data types to a minimum. 
    
    Would this be a reasonable compromise? 
    
    If general opinion is that unsigned types should not be part of
    postgres, I'll have to look at turning them into a contrib type. Please
    let me know.
    
    Cheers,
    
    Adriaan