semi-variable length type
I want to make a float(n) type that emulates the mssql float type. The storage requirements are documented as 4 bytes for 1 <= n <=24, and 8 bytes for 25 <= n <= 53. If I understand correctly, my options for emulating this in postgres are:
1. declare as variable length. Storage is then 8 bytes (4 byte length + 4 byte storage), or 12 bytes (4 byte length + 8 byte storage).
2. declare as fixed 8 byte length.
In the absence of some magical 3rd option, I assume #2 is the best way forward... can anyone confirm?
Thanks
James
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
James Harper <james.harper@bendigoit.com.au> writes:
I want to make a float(n) type that emulates the mssql float type. The
storage requirements are documented as 4 bytes for 1 <= n <=24, and 8
bytes for 25 <= n <= 53.
Haven't we got that already?
regression=# create table t1 (f1 float(5), f2 float(30));
CREATE TABLE
regression=# \d t1
Table "public.t1"
Column | Type | Modifiers
--------+------------------+-----------
f1 | real |
f2 | double precision |
Other than the fact that we don't remember whether you asked for 5 bits
or 24, I think this meets the spec requirements.
If I understand correctly, my options for
emulating this in postgres are: 1. declare as variable length. Storage
is then 8 bytes (4 byte length + 4 byte storage), or 12 bytes (4 byte
length + 8 byte storage).
Well, you could use a short varlena header (1 byte). The type doesn't
need to be int-aligned, either, though whether that buys anything will
depend on context --- and you'll need to spend cycles realigning it,
if you want the code to work on non-Intel architectures.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
James Harper <james.harper@bendigoit.com.au> writes:
I want to make a float(n) type that emulates the mssql float type. The
storage requirements are documented as 4 bytes for 1 <= n <=24, and 8
bytes for 25 <= n <= 53.Haven't we got that already?
regression=# create table t1 (f1 float(5), f2 float(30));
CREATE TABLE
regression=# \d t1
Table "public.t1"
Column | Type | Modifiers
--------+------------------+-----------
f1 | real |
f2 | double precision |Other than the fact that we don't remember whether you asked for 5 bits
or 24, I think this meets the spec requirements.
Is the 4 byte or 8 byte decision based on (n) implemented in the parser? I can't see a 'float' type in pg_type.
Thanks
James
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
James Harper <james.harper@bendigoit.com.au> writes:
regression=# create table t1 (f1 float(5), f2 float(30));
CREATE TABLE
regression=# \d t1
Table "public.t1"
Column | Type | Modifiers
--------+------------------+-----------
f1 | real |
f2 | double precision |Other than the fact that we don't remember whether you asked for 5 bits
or 24, I think this meets the spec requirements.
Is the 4 byte or 8 byte decision based on (n) implemented in the parser? I can't see a 'float' type in pg_type.
Yeah, gram.y is hard-wired to produce either "float4" or "float8" from
float(N) (see the opt_float production).
Ordinarily I'd think that that was a pretty sucky implementation
technique, but since this is implementing behavior called for in
the SQL standard, it's probably not worth trying to make it
any more flexible.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general