Re: Unsigned int functions
От | Adriaan Joubert |
---|---|
Тема | Re: Unsigned int functions |
Дата | |
Msg-id | 3AC41B6A.C409A7C@albourne.com обсуждение исходный текст |
Ответ на | Re: Unsigned int functions (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: