From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | James Harper <james(dot)harper(at)bendigoit(dot)com(dot)au> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: semi-variable length type |
Date: | 2014-02-21 14:40:47 |
Message-ID: | 31967.1392993647@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
James Harper <james(dot)harper(at)bendigoit(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Susan Cassidy | 2014-02-21 17:40:46 | problem with query and group by error |
Previous Message | loref85 | 2014-02-21 13:50:43 | Read tables of sql server with postgres |