| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Infinities in type numeric |
| Date: | 2020-06-16 13:33:44 |
| Message-ID: | 1299428.1592314424@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Vik Fearing <vik(at)postgresfriends(dot)org> writes:
> On 6/12/20 7:00 PM, Tom Lane wrote:
>> If we did that, you'd never see Inf in a
>> standard-conforming column, since SQL doesn't allow unconstrained
>> numeric columns IIRC.
> It does. The precision and scale are both optional.
> If the precision is missing, it's implementation defined; if the scale
> is missing, it's 0.
Ah, right, the way in which we deviate from the spec is that an
unconstrained numeric column doesn't coerce every entry to scale 0.
Still, that *is* a spec deviation, so adding "... and it allows Inf"
doesn't seem like it's making things worse for spec-compliant apps.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2020-06-16 13:43:58 | Re: Transactions involving multiple postgres foreign servers, take 2 |
| Previous Message | Tom Lane | 2020-06-16 13:30:09 | Re: language cleanups in code and docs |