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