Re: range_agg - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: range_agg
Date
Msg-id CAFj8pRA+bBBE_4toavfzjXAOT7JssDj8uiHLjdZtFpfUQzRyMA@mail.gmail.com
Whole thread Raw
In response to Re: range_agg  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


po 20. 1. 2020 v 1:38 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> On Sun, Jan 19, 2020 at 12:10 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Now, I think so name "anymultirange" is not good. Maybe better name is just "multirange"

> Are you sure? This function exists to be a cast to an anymultirange,
> and I thought the convention was to name cast functions after their
> destination type.

True for casts involving concrete types, mainly because we'd like
the identity "value::typename == typename(value)" to hold without
too much worry about whether the latter is a plain function call
or a special case.  Not sure whether it makes as much sense for
polymorphics, since casting to a polymorphic type is pretty silly:
we do seem to allow you to do that, but it's a no-op.

I'm a little troubled by the notion that what you're talking about
here is not a no-op (if it were, you wouldn't need a function).
That seems like there's something fundamentally not quite right
either with the design or with how you're thinking about it.

I thinking about completeness of operations

I can to write

CREATE OR REPLACE FUNCTION fx(anyarray, anyelement)
RETURNS anyarray AS $$
SELECT $1 || ARRAY[$2]
$$ LANGUAGE sql;

I need to some functionality for moving a value to different category (it is more generic than casting to specific type (that can hold category)

CREATE OR REPLACE FUNCTION fx(anymultirange, anyrange)
RETURNS anyrage AS $$
SELECT $1 + multirange($1)
$$ LANGUAGE sql;

is just a analogy.

Regards

Pavel


As a comparison point, we sometimes describe subscripting as
being a polymorphic operation like

        subscript(anyarray, integer) returns anyelement

It would be completely unhelpful to call that anyelement().
I feel like you might be making a similar mistake here.

Alternatively, consider this: a cast from some concrete multirange type
to anymultirange is a no-op, while any other sort of cast probably ought
to be casting to some particular concrete multirange type.  That would
line up with the existing operations for plain ranges.





                        regards, tom lane

pgsql-hackers by date:

Previous
From: Prabhu R
Date:
Subject: Master Master replication
Next
From: Craig Ringer
Date:
Subject: Re: Master Master replication