Re: access numeric data in module - Mailing list pgsql-hackers

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@gmail.com> wrote:

On Mon, Sep 9, 2024 at 2:02 PM Tom Lane <tgl@sss.pgh.pa.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