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
