| 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: | Whole Thread | Raw Message | 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 |