Re: POC: rational number type (fractions)
The discussion diverged somewhat to PGXN and extensions in general, but the consensus seems to be that this should (continue to) be an extension rather than a core feature. I agree that as an extension this is pretty cool. I'll mark this as rejected in the commitfest app. Looking at the patch, it looks well-structured and commented. - Heikki
Re: POC: rational number type (fractions)
On 2020-07-03 18:18, Tom Lane wrote: Andrew Dunstan writes: On 7/2/20 10:01 AM, Tom Lane wrote: Yeah. We *must not* simply give up on extensibility and decide that every interesting feature has to be in core. I don't have any great ideas about how we grow the wider Postgres development community and infrastructure, but that certainly isn't the path to doing so. I've been thinking about this a bit. Right now there isn't anything outside of core that seems to work well. PGXN was supposed to be our CPAN equivalent, but it doesn't seem to have worked out that way, it never really got the traction. Yeah. Can we analyze why it hasn't done better? Can we improve it rather than starting something completely new? This should probably all be in a different thread. But yeah, I think a bit more analysis of the problem is needed before jumping into action. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: POC: rational number type (fractions)
Andrew Dunstan writes: > On 7/2/20 10:01 AM, Tom Lane wrote: >> Yeah. We *must not* simply give up on extensibility and decide that >> every interesting feature has to be in core. I don't have any great >> ideas about how we grow the wider Postgres development community and >> infrastructure, but that certainly isn't the path to doing so. > I've been thinking about this a bit. Right now there isn't anything > outside of core that seems to work well. PGXN was supposed to be our > CPAN equivalent, but it doesn't seem to have worked out that way, it > never really got the traction. Yeah. Can we analyze why it hasn't done better? Can we improve it rather than starting something completely new? > I'm thinking about something different, > in effect a curated set of extensions, maintained separately from the > core. Probably the involvement of one or two committers would be good, > but the idea is that in general core developers wouldn't need to be > concerned about these. For want of a better name let's call it > postgresql-extras. I would undertake to provide buildfarm support, and > possibly we would provide packages to complement the PGDG yum and apt > repos. If people think that's a useful idea then those of us who are > prepared to put in some effort on this can take the discussion offline > and come back with a firmer proposal. My only objection to this idea is that competing with PGXN might not be a great thing. But then again, maybe it would be. Or maybe this is an intermediate tier between PGXN and core. Anyway, it certainly seems worth spending more thought on. I agree that we need to do *something* proactive rather than just hoping the extension community gets stronger by itself. regards, tom lane
Re: POC: rational number type (fractions)
On 7/2/20 10:01 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 7/1/20 7:00 PM, Stephen Frost wrote: >>> ... extensions outside of PG simply don't thrive as independent projects. >>> >>> There's various potential reasons for that, from being hard to find, to >>> being hard to install and work with, to the fact that we don't have a >>> centralized extension system (PGXN isn't really endorsed at all by >>> core... and I don't really think it should be), and our general >>> extension management system isn't particularly great anyway. >> Then these are things we should fix. But the right fix isn't including >> every extension in the core code. > Yeah. We *must not* simply give up on extensibility and decide that > every interesting feature has to be in core. I don't have any great > ideas about how we grow the wider Postgres development community and > infrastructure, but that certainly isn't the path to doing so. > > I've been thinking about this a bit. Right now there isn't anything outside of core that seems to work well. PGXN was supposed to be our CPAN equivalent, but it doesn't seem to have worked out that way, it never really got the traction. I'm thinking about something different, in effect a curated set of extensions, maintained separately from the core. Probably the involvement of one or two committers would be good, but the idea is that in general core developers wouldn't need to be concerned about these. For want of a better name let's call it postgresql-extras. I would undertake to provide buildfarm support, and possibly we would provide packages to complement the PGDG yum and apt repos. If people think that's a useful idea then those of us who are prepared to put in some effort on this can take the discussion offline and come back with a firmer proposal. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: POC: rational number type (fractions)
> > I think we mark this as rejected. Stephen Frost wrote: > The more we reject new things, the less appealing our community ends > up being. For what it's worth, I'm not disheartened if my rational patch is rejected. I can appreciate that postgres wants to avoid what might be feature creep, especially if aspects of the implementation are arbitrary or subject to change later on. It might be more productive for me to investigate other ways to contribute, like SQL:2016 features/conformance. That would increase our harmony with other databases, rather than adding idiosyncrasies like a new numeric type.
Re: POC: rational number type (fractions)
On 2020-07-02 16:21, Stephen Frost wrote: I don't see where I was either proposing that we give up extensibility, or that we have to include every extension in the core code. By the way, I have an extension that adds unsigned integer types. I would argue that that is more frequently requested than a fractions type. I'm not in favor of adding either to core, but just saying that if we think this one should be added, we might be opening up the floodgates a certain amount. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: POC: rational number type (fractions)
Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > On 7/1/20 7:00 PM, Stephen Frost wrote: > >> ... extensions outside of PG simply don't thrive as independent projects. > >> > >> There's various potential reasons for that, from being hard to find, to > >> being hard to install and work with, to the fact that we don't have a > >> centralized extension system (PGXN isn't really endorsed at all by > >> core... and I don't really think it should be), and our general > >> extension management system isn't particularly great anyway. > > > Then these are things we should fix. But the right fix isn't including > > every extension in the core code. > > Yeah. We *must not* simply give up on extensibility and decide that > every interesting feature has to be in core. I don't have any great > ideas about how we grow the wider Postgres development community and > infrastructure, but that certainly isn't the path to doing so. I don't see where I was either proposing that we give up extensibility, or that we have to include every extension in the core code. Thanks, Stephen signature.asc Description: PGP signature
Re: POC: rational number type (fractions)
Andrew Dunstan writes: > On 7/1/20 7:00 PM, Stephen Frost wrote: >> ... extensions outside of PG simply don't thrive as independent projects. >> >> There's various potential reasons for that, from being hard to find, to >> being hard to install and work with, to the fact that we don't have a >> centralized extension system (PGXN isn't really endorsed at all by >> core... and I don't really think it should be), and our general >> extension management system isn't particularly great anyway. > Then these are things we should fix. But the right fix isn't including > every extension in the core code. Yeah. We *must not* simply give up on extensibility and decide that every interesting feature has to be in core. I don't have any great ideas about how we grow the wider Postgres development community and infrastructure, but that certainly isn't the path to doing so. regards, tom lane
Re: POC: rational number type (fractions)
On 7/1/20 7:00 PM, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >>> I disagree with this and instead lean more towards the side that Robert >>> and Jeff were taking in that this would be a useful extension and >>> something we should consider including in core. I disagree with Tom and >>> Noah, specifically because, if we add this capability then I see our >>> potential use-cases as increasing and therefore getting more individuals >>> interested in working with us- to potentially include new contributors >>> and possibly committers. >> FWIW, I'm entirely in favor of having this available as an extension. >> But I'm not in favor of it being in core. I'm afraid it will end up >> like the geometric types, i.e. a backwater of not-very-good code that >> gets little love because it's not in line with the core competencies >> of a bunch of database geeks. If it's a separate project, then we >> could hope to attract interest from people who know the subject matter >> better but would never dare touch the PG backend in general. There's >> also the whole project-management issue that we have finite resources >> and so we can *not* afford to put every arguably-useful feature in core. > The issue that you highlight regarding geometric types is really that we > simply refuse to punt things from core, ever, and that's not a > reasonable position to take for long-term sanity. On the flip side, > it's ridiculously rare for an extension to have any kind of real > life as an independent project- yes, there's one big exception (PostGIS) > because it's simply ridiculously useful, and a few other cases > where one company/individual or another funds the work of a particular > extension because they need it for whatever, but by and large, > extensions outside of PG simply don't thrive as independent projects. > > There's various potential reasons for that, from being hard to find, to > being hard to install and work with, to the fact that we don't have a > centralized extension system (PGXN isn't really endorsed at all by > core... and I don't really think it should be), and our general > extension management system isn't particularly great anyway. > Then these are things we should fix. But the right fix isn't including every extension in the core code. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: POC: rational number type (fractions)
Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I disagree with this and instead lean more towards the side that Robert > > and Jeff were taking in that this would be a useful extension and > > something we should consider including in core. I disagree with Tom and > > Noah, specifically because, if we add this capability then I see our > > potential use-cases as increasing and therefore getting more individuals > > interested in working with us- to potentially include new contributors > > and possibly committers. > > FWIW, I'm entirely in favor of having this available as an extension. > But I'm not in favor of it being in core. I'm afraid it will end up > like the geometric types, i.e. a backwater of not-very-good code that > gets little love because it's not in line with the core competencies > of a bunch of database geeks. If it's a separate project, then we > could hope to attract interest from people who know the subject matter > better but would never dare touch the PG backend in general. There's > also the whole project-management issue that we have finite resources > and so we can *not* afford to put every arguably-useful feature in core. The issue that you highlight regarding geometric types is really that we simply refuse to punt things from core, ever, and that's not a reasonable position to take for long-term sanity. On the flip side, it's ridiculously rare for an extension to have any kind of real life as an independent project- yes, there's one big exception (PostGIS) because it's simply ridiculously useful, and a few other cases where one company/individual or another funds the work of a particular extension because they need it for whatever, but by and large, extensions outside of PG simply don't thrive as independent projects. There's various potential reasons for that, from being hard to find, to being hard to install and work with, to the fact that we don't have a centralized extension system (PGXN isn't really endorsed at all by core... and I don't really think it should be), and our general extension management system isn't particularly great anyway. The argument that we simply aren't able to ever extend the surface area of the database server beyond simple types because anything else requires specialized knowledge that general database hackers don't have implies that every committee/maintainers must be a general database hacker that knows all kinds of stuff about the innards of the kernel, but that isn't the case, even among our committers today- different folks have confidence working in different areas and that's an entirely good thing that allows us to increase our pool of resources while not expecting folks to be complete generalists. How do we build on that, while not ending up with code getting dumped on us and then left with us to maintain? That's the problem we need to solve, and perhaps other projects can give us insight, but I certainly won't accept that we simply must accept some glass ceiling regardless of how many people want to help us move forward- let's find a sensible way for them to help us move forward while not increasing drag to the point that we fall out of the sky. Thanks, Stephen signature.asc Description: PGP signature
Re: POC: rational number type (fractions)
Stephen Frost writes: > I disagree with this and instead lean more towards the side that Robert > and Jeff were taking in that this would be a useful extension and > something we should consider including in core. I disagree with Tom and > Noah, specifically because, if we add this capability then I see our > potential use-cases as increasing and therefore getting more individuals > interested in working with us- to potentially include new contributors > and possibly committers. FWIW, I'm entirely in favor of having this available as an extension. But I'm not in favor of it being in core. I'm afraid it will end up like the geometric types, i.e. a backwater of not-very-good code that gets little love because it's not in line with the core competencies of a bunch of database geeks. If it's a separate project, then we could hope to attract interest from people who know the subject matter better but would never dare touch the PG backend in general. There's also the whole project-management issue that we have finite resources and so we can *not* afford to put every arguably-useful feature in core. regards, tom lane
Re: POC: rational number type (fractions)
Greetings, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 5/22/20 1:53 AM, Noah Misch wrote: > > On Thu, May 21, 2020 at 01:40:10PM -0400, Robert Haas wrote: > >> On Mon, May 18, 2020 at 6:15 PM Tom Lane wrote: > >>> There surely are use-cases for true rational arithmetic, but I'm > >>> dubious that it belongs in core Postgres. I don't think that enough > >>> of our users would want it to justify expending core-project maintenance > >>> effort on it. So I'd be happier to see this as an out-of-core extension. > >> As is often the case, I'm a little more positive about including this > >> than Tom, but as is also often the case, I'm somewhat cautious, too. > >> On the one hand, I think it would be cool to have and people would > >> like it. But, On the other hand, I also think we'd only want it if > >> we're convinced that it's a really good implementation and that > >> there's not a competing design which is better, or even equally good. > > I vote for keeping it out of core, mostly because writing rational numeric > > code is so different from writing DBMS core code. (Many of our existing > > types, like numeric and the geometric types, have the same problem. Let's > > not > > invite more of that.) The optimal reviewer pools won't have much overlap, > > so > > patches may sit awhile and/or settle for a cursory review. > > > > More language standard libraries provide "numeric"-style big decimals[1] > > than > > provide big rationals[2], suggesting we're in good company. > > > > [1] > > https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software#Languages > > [2] https://en.wikipedia.org/wiki/Rational_data_type#Language_support > > I agree. Also the original rationale that people want to use it on RDS > is pretty awful. We can't just add in every extension that some DBAAS > provider doesn't support. I disagree with this and instead lean more towards the side that Robert and Jeff were taking in that this would be a useful extension and something we should consider including in core. I disagree with Tom and Noah, specifically because, if we add this capability then I see our potential use-cases as increasing and therefore getting more individuals interested in working with us- to potentially include new contributors and possibly committers. > I think we mark this as rejected. The more we reject new things, the less appealing our community ends up being. I don't mean that to be an argument that we should accept everything, but a new capability that has relatively little impact on the core code and is useful should be something we're leaning towards accepting rather than rejecting out of hand because it's not explicitly called out in the SQL standard or appeals to the masses. I'll further say that this is where we end up potentially loosing newcomers to writing their own code in python or other tools when, if we had such support in core, they'd be able to accomplish what they want more easily with PG. Thanks, Stephen signature.asc Description: PGP signature
Re: POC: rational number type (fractions)
On 5/22/20 1:53 AM, Noah Misch wrote: > On Thu, May 21, 2020 at 01:40:10PM -0400, Robert Haas wrote: >> On Mon, May 18, 2020 at 6:15 PM Tom Lane wrote: >>> There surely are use-cases for true rational arithmetic, but I'm >>> dubious that it belongs in core Postgres. I don't think that enough >>> of our users would want it to justify expending core-project maintenance >>> effort on it. So I'd be happier to see this as an out-of-core extension. >> As is often the case, I'm a little more positive about including this >> than Tom, but as is also often the case, I'm somewhat cautious, too. >> On the one hand, I think it would be cool to have and people would >> like it. But, On the other hand, I also think we'd only want it if >> we're convinced that it's a really good implementation and that >> there's not a competing design which is better, or even equally good. > I vote for keeping it out of core, mostly because writing rational numeric > code is so different from writing DBMS core code. (Many of our existing > types, like numeric and the geometric types, have the same problem. Let's not > invite more of that.) The optimal reviewer pools won't have much overlap, so > patches may sit awhile and/or settle for a cursory review. > > More language standard libraries provide "numeric"-style big decimals[1] than > provide big rationals[2], suggesting we're in good company. > > [1] > https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software#Languages > [2] https://en.wikipedia.org/wiki/Rational_data_type#Language_support > > I agree. Also the original rationale that people want to use it on RDS is pretty awful. We can't just add in every extension that some DBAAS provider doesn't support. I think we mark this as rejected. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: POC: rational number type (fractions)
On Thu, May 21, 2020 at 01:40:10PM -0400, Robert Haas wrote: > On Mon, May 18, 2020 at 6:15 PM Tom Lane wrote: > > There surely are use-cases for true rational arithmetic, but I'm > > dubious that it belongs in core Postgres. I don't think that enough > > of our users would want it to justify expending core-project maintenance > > effort on it. So I'd be happier to see this as an out-of-core extension. > > As is often the case, I'm a little more positive about including this > than Tom, but as is also often the case, I'm somewhat cautious, too. > On the one hand, I think it would be cool to have and people would > like it. But, On the other hand, I also think we'd only want it if > we're convinced that it's a really good implementation and that > there's not a competing design which is better, or even equally good. I vote for keeping it out of core, mostly because writing rational numeric code is so different from writing DBMS core code. (Many of our existing types, like numeric and the geometric types, have the same problem. Let's not invite more of that.) The optimal reviewer pools won't have much overlap, so patches may sit awhile and/or settle for a cursory review. More language standard libraries provide "numeric"-style big decimals[1] than provide big rationals[2], suggesting we're in good company. [1] https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software#Languages [2] https://en.wikipedia.org/wiki/Rational_data_type#Language_support
Re: POC: rational number type (fractions)
On Mon, May 18, 2020 at 6:15 PM Tom Lane wrote: > There surely are use-cases for true rational arithmetic, but I'm > dubious that it belongs in core Postgres. I don't think that enough > of our users would want it to justify expending core-project maintenance > effort on it. So I'd be happier to see this as an out-of-core extension. As is often the case, I'm a little more positive about including this than Tom, but as is also often the case, I'm somewhat cautious, too. On the one hand, I think it would be cool to have and people would like it. But, On the other hand, I also think we'd only want it if we're convinced that it's a really good implementation and that there's not a competing design which is better, or even equally good. Those things don't seem too clear at this point, so I hope Jeff and Joe keep chatting about it ... and maybe some other people who are knowledgeable about this will chime in, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: POC: rational number type (fractions)
Chapman Flack writes: > On 05/18/20 17:33, Peter Eisentraut wrote: >> The numeric type already stores rational numbers. How is this different? >> What's the use? > Won't ever quite represent, say, 1/3, no matter how big you let it get. There surely are use-cases for true rational arithmetic, but I'm dubious that it belongs in core Postgres. I don't think that enough of our users would want it to justify expending core-project maintenance effort on it. So I'd be happier to see this as an out-of-core extension. (That'd also ease dealing with the prospect of having more than one variant, as was mentioned upthread.) regards, tom lane
Re: POC: rational number type (fractions)
On 05/18/20 17:33, Peter Eisentraut wrote: > The numeric type already stores rational numbers. How is this different? > What's the use? Seems like numeric is a base-1 representation. Will work ok for a rational whose denominator factors into 2s and 5s. Won't ever quite represent, say, 1/3, no matter how big you let it get. Regards, -Chap
Re: POC: rational number type (fractions)
On 2020-02-08 05:25, Joe Nelson wrote: Hi hackers, attached is a proof of concept patch adding a new base type called "rational" to represent fractions. It includes arithmetic, simplification, conversion to/from float, finding intermediates with a stern-brocot tree, custom aggregates, and btree/hash indices. The numeric type already stores rational numbers. How is this different? What's the use? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: POC: rational number type (fractions)
Hi Joe, On 2/7/20 11:25 PM, Joe Nelson wrote: Hi hackers, attached is a proof of concept patch adding a new base type called "rational" to represent fractions. I have set the target version for this patch to PG14 because it is POC and this is the first CF it has appeared in. Regards, -- -David da...@pgmasters.net
Re: POC: rational number type (fractions)
On Fri, 2020-02-21 at 19:24 -0600, Joe Nelson wrote: > I could imagine having two types, a rational8 for the current > implementation, and an arbitrary precision rational. Perhaps... The main thing I'm trying to avoid is a situation where we introduce "rational", but it only meets a subset of the use cases, and then we end up with another extension. I'm not saying that's happening here, but it would be good to compare against other implementations (for instance from normal programming languages) to see if we are missing some use cases. If you are using rational to track positions of items in an online to- do list, and the user keeps swapping or rotating items in the list, is that going to lead to overflow/underflow? > > * what's the philosophy regarding NULL and rational? Why are NULL > > arguments returning non-NULL answers? > > The rational_intermediate(x, y) function picks a fraction between x > and > y, and NULL was meant as a signal that one of the sides is unbounded. > So rational_intermediate(x, NULL) means find a fraction larger than > x, > and rational_intermediate(NULL, y) means find one smaller than y. Would "x+1" or "y-1" also work for that? I am a little worried about introducing a function that is not well- defined. Would a midpoint function serve the purpose? > If there are already todos positioned after 2 then it'll find a spot > between 2 and the min. However if there are no todos after 2 then > min() > will return NULL and we'll simply find a position *somewhere* after > 2. Interesting. That could probably be solved with a COALESCE() around the MIN(), but your version is a little cleaner. > > * Is rational_intermediate() well-defined, or can it just choose > > any > > rational between the two arguments? > > It chooses the mediant [2] Maybe we should define it as the mediant then? > currently included these casts: integer -> rational, float8 <-> > rational. Don't have one for numeric yet. A cast to numeric would make sense. What will you do in cases where the domains don't quite match, are you rounding or truncating? Regards, Jeff Davis
Re: POC: rational number type (fractions)
Joe Nelson wrote: > where the denominator is made positive whenever possible (not possible > when it's -INT_MAX). (I meant INT_MIN rather than -INT_MAX.) Another more-than-one-way-to-do-it task is converting a float to a fraction. I translated John Kennedy's method [0] to C, but Github user adegert sent an alternative [1] that matches the way the CPython implementation works. 0: https://begriffs.com/pdf/dec2frac.pdf 1: https://github.com/begriffs/pg_rational/pull/13
Re: POC: rational number type (fractions)
Jeff Davis wrote: > The decision between an extension and a core type is a tricky one. To > put an extension in core, usually it's good to show either that it > satisfies something in the SQL standard, or that there is some > specific technical advantage (like integration with the syntax or the > type system). I don't see any references to "rational" in the SQL standard (fifth ed, 2016) and the only reference to "fraction" is for fractions of a second in datetime. Doesn't look like SQL includes rational numbers. Also I don't believe I'm getting extra abilities by putting this in core vs using an extension. Perhaps there's a syntax change that would make rationals more pleasant to deal with than how they in this patch, but I haven't imagined what it would be, and it's not backed by a standard. > Integrating it in core just to make it easier to use is a double-edge > sword. It does make it easier in some environments; but it also > removes pressure to make those environments offer better support for > the extension ecosystem, ultimately weakening extensions overall. Makes sense. We petitioned RDS to allow the pg_rational extension, [0] but they didn't respond. Not sure how that process is supposed to work. 0: https://github.com/begriffs/pg_rational/issues/7 > In this case I believe it could be a candidate for in-core, but it's > borderline. The reasons it makes sense to me are: > > 1. It seems that there's "only one way to do it". There may be more than one way to do it actually. For instance the choice between a fixed size type with limits on the fractions it can represent, vs one that can grow to hold any fraction. I chose the first option, to make the type the same size as float8. My reasoning was that there was would be no space overhead for choosing rational over float. Also there's the choice of whether to always store fractions in normal form (lowest terms). This patch allows fractions to be in non-normal form after arithmetic, and only normalizes as needed when an arithmetic operation would overflow. I wanted to cut down on how many times gcd is called. However this choice means that hash indices have to normalize because they hash the bit pattern, while btree indices can compare rationals without regard to normal form. This patch represents each rational as a separate numerator and denominator. I did some research today to see if there are any another ways, and looks like there's a technique from the 70s called "quote notation." [1] It appears that quote notation makes addition and subtraction faster, but that the operations can less predictable performance in the worst case scenarios with doing arbitrary precision. So there's more than one way to do it. 1: https://en.wikipedia.org/wiki/Quote_notation > 2. I don't expect this will be much of a maintenance burden. True, rational numbers aren't going to change anytime soon. > Keep in mind that if you do want this to be in core, the data format > has to be very stable to maintain pg_upgrade compatibility. The format is currently [int32 numerator][int32 denominator] packed together, where the denominator is made positive whenever possible (not possible when it's -INT_MAX). The quote notation alternative would arrange things very differently. > Patch comments: > > * Please include docs. Of course, if we determine the patch is desirable. The included tests should help demonstrate how it works for the purposes of review. > * I'm worried about the use of int32. Does that cover all of the > reasonable use cases of rational? I could imagine having two types, a rational8 for the current implementation, and an arbitrary precision rational. Perhaps... > * what's the philosophy regarding NULL and rational? Why are NULL > arguments returning non-NULL answers? The rational_intermediate(x, y) function picks a fraction between x and y, and NULL was meant as a signal that one of the sides is unbounded. So rational_intermediate(x, NULL) means find a fraction larger than x, and rational_intermediate(NULL, y) means find one smaller than y. The use case is a query for a spot "immediately after position 2:" SELECT rational_intermediate(2, min(pos)) FROM todos WHERE pos > 2; If there are already todos positioned after 2 then it'll find a spot between 2 and the min. However if there are no todos after 2 then min() will return NULL and we'll simply find a position *somewhere* after 2. > * Is rational_intermediate() well-defined, or can it just choose any > rational between the two arguments? It chooses the mediant [2] of x and y in lowest terms by walking a Stern-Brocot tree. I found that this keeps the terms of the fraction much smaller than taking the average of x and y. This was an advantage over calculating with floats because I don't know how to take the mediant of floats, and repeatedly taking the average of floats eats up precision pretty quickly. 2: https://en.wikipedia.org/wiki/Mediant_(mathematics) > * Can you discuss how
Re: POC: rational number type (fractions)
On Fri, 2020-02-07 at 22:25 -0600, Joe Nelson wrote: > Hi hackers, attached is a proof of concept patch adding a new base > type > called "rational" to represent fractions. Hi! > The primary motivation was as a column type to support user-defined > ordering of rows (with the ability to dynamically rearrange rows). > The > postgres wiki has a page [0] about this using pairs of integers to > represent fractions, but it's not particularly elegant. Sounds good. > I wrote about options for implementing user-defined order in an > article > [1] and ended up creating a postgres extension, pg_rational [2], to > provide the new type. People have been using the extension, but told > me > they wished they could use it on hosted platforms like Amazon RDS > which > have a limited set of whitelisted extensions. Thus I'm submitting > this > patch to discuss getting the feature in core postgres. The decision between an extension and a core type is a tricky one. To put an extension in core, usually it's good to show either that it satisfies something in the SQL standard, or that there is some specific technical advantage (like integration with the syntax or the type system). Integrating it in core just to make it easier to use is a double-edge sword. It does make it easier in some environments; but it also removes pressure to make those environments offer better support for the extension ecosystem, ultimately weakening extensions overall. In this case I believe it could be a candidate for in-core, but it's borderline. The reasons it makes sense to me are: 1. It seems that there's "only one way to do it". It would be good to validate that this really covers most of the use cases of rational numbers, but if so, that makes it a better candidate for building it into core. It would also be good to compare against other implementations (perhaps in normal programming languages) to see if there is anything interesting. 2. I don't expect this will be much of a maintenance burden. Keep in mind that if you do want this to be in core, the data format has to be very stable to maintain pg_upgrade compatibility. Patch comments: * Please include docs. * I'm worried about the use of int32. Does that cover all of the reasonable use cases of rational? * Shouldn't: /* * x = coalesce(lo, arg[0]) y = coalesce(hi, arg[1]) */ be: /* * x = coalesce(arg[0], lo) y = coalesce(arg[1], lo) */ * More generally, what's the philosophy regarding NULL and rational? Why are NULL arguments returning non-NULL answers? * Is rational_intermediate() well-defined, or can it just choose any rational between the two arguments? * Can you discuss how cross-type comparisons and conversions should be handled (e.g. int8, numeric, float8)? Regards, Jeff Davis
Re: POC: rational number type (fractions)
Hello, It seems you are not the first to be interested in such feature. There was a similar extension used in "incremental view maintenance" testing: https://github.com/nuko-yokohama/pg_fraction didn't tryed it myself. Regards PAscal -- Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
