From: | Pailloncy Jean-Gerard <jg(at)rilk(dot)com> |
---|---|
To: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Extended unit |
Date: | 2005-01-27 09:48:40 |
Message-ID: | b1ef5d24ec68884f380b5ebf8caa0b9d@rilk.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> ision 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 ?
No doable.
After you will need the factorial number of operator between all the
combinatory of couple of unit.
> As for the encoding, why not just use a (float, text) with the text
> as a parseable
I am doing test with this.
But constraint is done at execution time.
Space is larger.
Operation of two of these is slower than the native one (float).
I want to have it at parsing level to speed the error detection as
writing code.
> 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.
(float, text) versus (float)
with text is cd3.A2.sr.m-1.s-2.rad-3.kg-4
with an experiment of few milions of results that have few dozen of
parameter.
just to be sure that be not add at parser time meter with second.
I think this work-less, except for a proof of concept.
Cordialement,
Jean-Gérard Pailloncy
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2005-01-27 09:49:12 | Re: self-join on subselect |
Previous Message | Dawid Kuroczko | 2005-01-27 09:44:51 | Re: Lower case |