Re: access numeric data in module

Sorry for taking so long to respond. I was at my day-job.

As I mentioned, I am the maintainer of the PL/Haskell language extension.
This extension allows users to write code in the Haskell language. In order
to use numeric types, I will need to create a Haskell type equivalent.
Something like

data Numeric = PosInfinity | NegInfinity | NaN | Number Integer Int16

where the Number constructor represents a numeric's mantissa and weight.

In order to get or return data, I would need to be able to access those
fields of the numeric type.

I'm not proposing giving access to the actual numeric structure. Rather,
the data should be accessed by function call or macro. This would allow
future changes to the inner workings without breaking compatibility as long
as the interface is maintained. It looks to me like all of the code to
access data exists, it should simply be made accessible. An additional
function should exist that allows an extension to create a numeric
structure by passing the needed data.

-Ed

On Mon, Sep 9, 2024 at 2:45 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Sep 9, 2024 at 2:02 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > By that argument, we should move every declaration in every .c file
> > into c.h and be done. I'd personally be happier if we had *not*
> > exposed the other data structure details you mention, but that
> > ship has sailed.
>
> Not every declaration in every .c file is of general interest, but the
> ones that are probably should be moved into .h files. The on-disk
> representation of a commonly-used data type certainly qualifies.
>
> You can see from Chapman's reply that I'm not making this up: when we
> don't expose things, it doesn't keep people from depending on them, it
> just makes them copy our code into their own repository. That's not a
> win. It makes those extensions more fragile, not less, and it makes
> the PostgreSQL extension ecosystem worse. pg_hint_plan is another,
> recently-discussed example of this phenomenon: refuse to give people
> the keys, and they start hot-wiring stuff.
>
> > If we do do what you're advocating, I'd at least insist that the
> > declarations go into a new file numeric_internal.h, so that it's
> > clear to all concerned that they're playing with fire if they
> > depend on that stuff.
>
> I think that's a bit pointless considering that we don't do it in any
> of the other cases. I'd rather be consistent with our usual practice.
> But if it ends up in a separate header file that's still better than
> the status quo.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>