From: | Ed Behn <ed(at)behn(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: access numeric data in module |
Date: | 2024-09-14 18:09:58 |
Message-ID: | CAJBL5DPmqdYH8pnEUTE2T4m_qtRi_JBcR+3siziYRccQCcW6Gg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <ed(at)behn(dot)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 <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
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Akshat Jaimini | 2024-09-14 18:57:21 | Re: WAL_LOG CREATE DATABASE strategy broken for non-standard page layouts |
Previous Message | Tom Lane | 2024-09-14 17:50:00 | Re: Psql meta-command conninfo+ |