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
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) |