Re: Reducing NUMERIC size for 8.3

From: Zdenek(dot)Kotala(at)Sun(dot)COM
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing NUMERIC size for 8.3
Date: 2007-09-26 15:07:41
Message-ID: 46FA75BD.5040705@Sun.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan wrote:

>
>
> Zdenek Kotala wrote:
>
>> Tom Lane wrote:
>>
>>> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>>>
>>>> We previously discussed compressing the numeric data type for small
>>>> values:
>>>> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
>>>
>>>
>>>> We didn't do this for 8.3 but in any case Tom did suggest we ought
>>>> to reverse
>>>> the weight and sign/dscale so we could do this sometime without
>>>> introducing
>>>> another incompatibility.
>>>
>>>
>>> I had forgotten about that, but it does seem like a good idea to do
>>> it now.
>>> Any objections?
>>
>>
>> For in-place upgrade purpose It would be good change also OID for
>> numeric type and preserve current OID for current implementation on
>> updated system.
>>
>>
>>
>
>
> If we want to get into that game we need a better way of allocating
> Oids. Right now anything not currently used is liable to be grabbed,
> so there's a high risk of reuse.

Yes, it will be necessary. Or maybe second way is create only really
base types (name, int, bool ...) on bootstrap and others types will be
created in standard manner by CREATE TYPE, CREATE OPERATOR ...
commands. Or third way is not remove old datatypes and only rename them
to e.g. numeric_old1 ...

Zdenek

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2007-09-26 16:05:24 Re: [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)
Previous Message Tom Lane 2007-09-26 15:04:52 uh-oh, dugong failing again (was Re: Pgbuildfarm-status-green Digest, Vol 28, Issue 24)