Re: Reducing NUMERIC size for 8.3

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

In response to

Browse pgsql-hackers by date

  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