From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reducing NUMERIC size for 8.3 |
Date: | 2007-09-24 17:00:56 |
Message-ID: | 87wsugngl3.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>
>> I think we also should move the NumericData and declaration to numeric.c and
>> make the Numeric type an opaque pointer for the rest of the source
>> tree.
>
> I don't agree with that; we are not in the habit of doing it that way
> for any other on-disk data type. All it will accomplish is to force
> people to make private copies of the struct declaration, thereby
> entirely guaranteeing that they fail to track changes. There will
> always be legitimate reasons for external code to want to look at
> on-disk bits.
Well the macros to do so would become quite a bit more complex. I imagine they
would become functions instead. I suppose a reasonable simple interface could
be ginned up. But anyone currently accessing the data directly would have to
go through the functions to access the bits.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-09-24 17:04:25 | Re: GUC variable renaming, redux |
Previous Message | Tom Lane | 2007-09-24 16:50:13 | Re: GUC variable renaming, redux |