Re: Extended unit
От | PFC |
---|---|
Тема | Re: Extended unit |
Дата | |
Msg-id | opsk8m08tmth1vuj@musicbox обсуждение исходный текст |
Ответ на | Re: Extended unit (Csaba Nagy <nagy@ecircle-ag.com>) |
Ответы |
Re: Extended unit
|
Список | pgsql-general |
> I wonder if it makes sense to implement the units as separate data types > ? Cause that's what they are really. > So "amper" would be a data type which aliases one of the numeric data > types (depending on what precision range you need), but does not allow > to be added with anything else than "amper". Any other interaction with > other units (read data types) would be achieved by defining the needed > operators on the respective data types (read units). You'd have to create a postgres datatype for every variation on m, m/s, m/s², etc... which would be kinda unworkable... I think it's better to have one datatype (number with unit) and have the operators raise an exception when trying to add incompatible units ? As for the encoding, why not just use a (float, text) with the text as a parseable representation of the unit, which could as well be the SI unit (like m/s) which would be a lot more flexible than bitfields. Problem is I think it'll always be variable length. Maybe there is enough space in an int64 to fit it all ? Maybe with huffman coding ? Is it really important to save a few bytes ? I don't think so. For table columns, the type would be saved in the column definition so you'd just have a float anyway. I think it's an exciting project !
В списке pgsql-general по дате отправления: