From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: range_agg |
Date: | 2020-01-24 07:08:56 |
Message-ID: | CAFj8pRDzeTv9vs6mBdasE+ogduq78aXFyKU2X0Py1UcgDQ-8_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
st 22. 1. 2020 v 0:55 odesílatel Paul A Jungwirth <
pj(at)illuminatedcomputing(dot)com> napsal:
> On Sun, Jan 19, 2020 at 9:57 PM Paul A Jungwirth
> <pj(at)illuminatedcomputing(dot)com> wrote:
> > On Sun, Jan 19, 2020 at 4:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > 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.
> > >
> > > ...
> > >
> > > 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.
> >
> > I agree you wouldn't actually cast by saying x::anymultirange, and the
> > casts we define are already concrete, so instead you'd say
> > x::int4multirange. But I think having a polymorphic function to
> > convert from an anyrange to an anymultirange is useful so you can
> > write generic functions. I can see how calling it "anymultirange" may
> > be preferring the implementor perspective over the user perspective
> > though, and how simply "multirange" would be more empathetic. I don't
> > mind taking that approach.
>
> Here is a patch with anymultirange(anyrange) renamed to
> multirange(anyrange). I also rebased on the latest master, added
> documentation about the multirange(anyrange) function, and slightly
> adjusted the formatting of the range functions table.
>
I think so this patch is ready for commiter.
All tests passed, the doc is good enough (the chapter name "Range functions
and Operators" should be renamed to "Range/multirange functions and
Operators"
The code formatting and comments looks well
Thank you for your work
Regards
Pavel
> Thanks,
> Paul
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-01-24 07:13:01 | Re: [PATCH] Windows port, fix some resources leaks |
Previous Message | Mike Lissner | 2020-01-24 07:01:36 | Patching documentation of ALTER TABLE re column type changes on binary-coercible fields |