Re: Fixed length data types issue - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Fixed length data types issue
Date
Msg-id 87venup2xn.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> No, that got rejected as being too much of a restriction of the dynamic
> range, eg John's comment here:
> http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php

That logic seems questionable. John makes two points:

a) crypto applications are within a factor of two of the proposed limitation.

Firstly, nobody does actual crypto work using Postgres's numeric data type. It
would be ridiculously slow. They wouldn't even store numbers used for crypto
in it, they would use bytea or something like that to store a binary
bitstring. 

Secondly, there's nothing blocking us from changing it again in the future. It
would make pg_upgrade a pain but solving user-defined datatypes being
redefined would be a necessity anyways. A future version could always revert
the change.

b) Because we're usually not especially concerned with CPU usage of numeric
we're also not concerned with space usage of numeric.

I'm not sure what the arguments were that he's referring to but I have trouble
imagining a credible argument against being concerned for cpu usage that
wouldn't result in the conclusion that space usage was *more* important.

I was actually going to suggest going back and looking for *more* space
savings in numeric. I had assumed this first step had gone in long ago.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Buildfarm vs. Linux Distro classification
Next
From: Tom Lane
Date:
Subject: Re: Fixed length data types issue