Good afternoon-
Was there a resolution of this? I'm wondering if it is worth it for me
to submit a PR for the next commitfest.
-Ed
On Mon, Sep 9, 2024 at 8:40 PM Ed Behn <e...@behn.us> wrote:
> 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 <robertmh...@gmail.com> wrote:
>
>> On Mon, Sep 9, 2024 at 2:02 PM Tom Lane <t...@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
>>
>
