| From: | Ed Behn <ed(at)behn(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: access numeric data in module |
| Date: | 2025-03-01 20:32:47 |
| Message-ID: | CAJBL5DNgNF3DZF6oKN12j6Dd-=UhR2nAEK+RxzfQtTdRgvjqoA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom-
I think that I can allay your concerns. Please give me a day or so to
put together my more complete thoughts on the matter. I'll be in touch.
-Ed
On Sat, Mar 1, 2025 at 11:33 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ed Behn <ed(at)behn(dot)us> writes:
> >> There is actually no new code. Code is simply moved from numeric.c to
> >> numeric.h.
>
> I will absolutely not hold still for that. It would mean that any
> time we want to think about messing with the contents of numerics,
> we need to examine more or less the whole Postgres code base to see
> what else is poking into those structures.
>
> If we must do something like this, then a separate header
> "numeric_internal.h" or something like that would reduce the blast
> radius for changes. But IMO you still haven't made an acceptable case
> for deciding that these data structures aren't private to numeric.c.
> What behaviors do you actually need that aren't accessible via the
> existing exported functons?
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2025-03-01 20:48:18 | Re: Statistics Import and Export |
| Previous Message | Tom Lane | 2025-03-01 18:56:51 | Re: Statistics Import and Export |