pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: range_agg
Date: Sun, 19 Jan 2020 19:38:13 -0500
Message-ID: <27619.1579480693@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+renyWzGGq38iv_hD4OE7AfHbxLJOtHAMtit=axJw6QdjdVQg@mail.gmail.com>
References: <CA+renyXaiH6c7xyfSCtOu_3UU2qFvP17v4m9zAM7w-_UokeScg@mail.gmail.com>
	<20191220192901.GA9955@alvherre.pgsql>
	<CA+renyWmmrTcyxoCozqynkpG82XDg_W5NHKLztADKkzcTLZmmA@mail.gmail.com>
	<CAFj8pRDn-f9-2jbUfR4XpVXiTwfcGo5CKYk8y2ktzdm64vVmTg@mail.gmail.com>
	<CA+renyVfMGDpuXjx=jUjUaw2euqkQLEDazkZhjs76qOXN0ocwA@mail.gmail.com>
	<CAFj8pRAaMrD0OcWmQfxQ_SN7ZMYOB_7Yak9Eb==KfMT6OMrttg@mail.gmail.com>
	<CA+renyW=n2bbJSBtaeK1-a1KrfXBPxKbkc5VZbTSzA0B9gthkg@mail.gmail.com>
	<CAFj8pRDw3Aa67N-iOR2+Qoj49QocLJDr73jbqYwVS3XL0bxvxw@mail.gmail.com>
	<CAFj8pRDYkdi4vDmKTAL-7dQqX5CbxHzAzkn=VH=ojZc9F+mbcw@mail.gmail.com>
	<CA+renyWzGGq38iv_hD4OE7AfHbxLJOtHAMtit=axJw6QdjdVQg@mail.gmail.com>

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.

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





view thread (152+ messages)  latest in thread

Message-ID: <27619.1579480693@sss.pgh.pa.us>
Permalink:  ../27619.1579480693@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/27619.1579480693@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pj@illuminatedcomputing.com, pavel.stehule@gmail.com, alvherre@2ndquadrant.com, pgsql@j-davis.com
  Subject: Re: range_agg
  In-Reply-To: <27619.1579480693@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox