Tom-
I understand that you are concerned about future maintenance costs vs
benefits of this change. I hope that I can address those concerns. An
important thing to note is that there are two different structures that
represent numeric values:
* NumericData is an opaque structure that is def
On Sat, 1 Mar 2025 at 17:33, Tom Lane wrote:
> 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?
FWIW in pg_duckdb we would def
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 wrote:
> Ed Behn writes:
> >> There is actually no new code. Code is simply moved
Ed Behn 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
Upon further review, I've updated the patch. This avoids possible name
conflicts with other functions. See attached.
On Sat, Feb 8, 2025 at 3:24 PM Ed Behn wrote:
> I've created a patch (attached) to implement the changes discussed below.
>
> This change moves the definition of the NumericVar st
I've created a patch (attached) to implement the changes discussed below.
This change moves the definition of the NumericVar structure to numeric.h.
Function definitions for functions used to work with NumericVar are also
moved to the header as are definitions of functions used to convert
NumericV
On Sat, Sep 14, 2024 at 2:10 PM Ed Behn wrote:
> Was there a resolution of this? I'm wondering if it is worth it for me to
> submit a PR for the next commitfest.
Well, it seems like what you want is different than what I want, and
what Tom wants is different from both of us. I'd like there t
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 wrote:
> Sorry for taking so long to respond. I was at my day-job.
>
> As I mentioned, I am the maintainer
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
dat
On Mon, Sep 9, 2024 at 2:02 PM Tom Lane 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 ever
On 09/09/24 13:00, Robert Haas wrote:
> I don't agree with this reponse at all. It seems entirely reasonable
> for third-party code to want to have a way to construct and interpret
> numeric datums. Keeping the details private would MAYBE make sense if
> the internal details were changing release t
Robert Haas writes:
> On Mon, Sep 9, 2024 at 1:25 PM Tom Lane wrote:
>> IMO it'd be a lot better if numeric.c exposed whatever functionality
>> Ed feels is missing, while keeping the contents of a numeric opaque.
> We could certainly expose a bunch of functions, but I think that would
> actually
On Mon, Sep 9, 2024 at 1:25 PM Tom Lane wrote:
> We have changed numeric's internal representation in the past, and
> I'd like to keep the freedom to do so again. There's been discussion
> for example of reconsidering the choice of NBASE to make more sense
> on 64-bit hardware. Yeah, maintaining
Robert Haas writes:
> On Mon, Sep 9, 2024 at 10:14 AM Tom Lane wrote:
>> It's intentional that that stuff is not exposed, so no.
>> What actual functionality do you need that numeric.h doesn't expose?
> I don't agree with this reponse at all. It seems entirely reasonable
> for third-party code t
On Mon, Sep 9, 2024 at 10:14 AM Tom Lane wrote:
> Ed Behn writes:
> > I want to be able to have a function received and/or return numeric data.
> > However, I'm having trouble getting data from Datums and building Datums to
> > return. numeric.h does not contain the macros to do this. They are in
Ed Behn writes:
> I want to be able to have a function received and/or return numeric data.
> However, I'm having trouble getting data from Datums and building Datums to
> return. numeric.h does not contain the macros to do this. They are in
> numeric.c.
> Is there a way to access the values in t
I'm the maintainer of the PL/Haskell language extension. (
https://github.com/ed-o-saurus/PLHaskell/)
I want to be able to have a function received and/or return numeric data.
However, I'm having trouble getting data from Datums and building Datums to
return. numeric.h does not contain the macros
17 matches
Mail list logo
