This patch has been committed. I split it into a few pieces.
On 12.03.22 04:18, Paul Jungwirth wrote:
On 3/10/22 14:07, Chapman Flack wrote:
When I apply this patch, I get a func.sgml with two entries for
range_intersect_agg(anymultirange).
Arg, fixed.
In range_agg_transfn, you've changed
Fwiw the cfbot is failing due to a duplicate OID. Traditionally we
didn't treat duplicate OIDs as reason to reject a patch because
they're inevitable as other patches get committed and the committer
can just renumber them.
I think the cfbot kind of changes this calculus since it's a pain lose
the
On 03/11/22 22:18, Paul Jungwirth wrote:
> Arg, fixed.
>
>> In range_agg_transfn, you've changed the message in the "must be called
>> with a range or multirange"; that seems like another good candidate to
>> be an elog.
>
> Agreed. Updated here.
This looks good to me and passes installcheck-wor
review, and sorry for so many iterations! :-)
Yours,
--
Paul ~{:-)
p...@illuminatedcomputing.comFrom b409d7333132e34a928ec8cc0ecca0a3421b7268 Mon Sep 17 00:00:00 2001
From: "Paul A. Jungwirth"
Date: Fri, 10 Dec 2021 16:04:57 -0800
Subject: [PATCH v4] Add range_agg with multir
On 03/05/22 15:53, Paul Jungwirth wrote:
> On 3/1/22 13:33, Chapman Flack wrote:
>> I think the 4 lines should suffice, but it looks like this patch was
>> generated from a rebase of the old one (with three lines) that ended up
>> putting the new 'range_agg' en
On 3/1/22 13:33, Chapman Flack wrote:
I think the 4 lines should suffice, but it looks like this patch was
generated from a rebase of the old one (with three lines) that ended up
putting the new 'range_agg' entry ahead of 'max' in func.sgml, which
position is now baked
! Rebase attached.
I think the 4 lines should suffice, but it looks like this patch was
generated from a rebase of the old one (with three lines) that ended up
putting the new 'range_agg' entry ahead of 'max' in func.sgml, which
position is now baked into the 4 lines of context. :)
ERROR,
+ (errcode(ERRCODE_DATATYPE_MISMATCH),
+errmsg("range_agg must be called with a multirange")));
I agree it would be more helpful to users to let them know we can take
either kind of argument. I changed the message to "range_agg must be
called with a range
ge in the new
multirange_agg_transfn:
+ if (!type_is_multirange(mltrngtypoid))
+ ereport(ERROR,
+ (errcode(ERRCODE_DATATYPE_MISMATCH),
+errmsg("range_agg must be called with a multirange")));
It's clearly copied from the corresponding
Here is a patch adding range_agg(anymultirange). Previously range_agg
only accepted anyrange.
Here is a bug report from last month requesting this addition:
https://www.postgresql.org/message-id/CAOC8YUcOtAGscPa31ik8UEMzgn8uAWA09s6CYOGPyP9_cBbWTw%40mail.gmail.com
As that message points out
On Sun, Dec 27, 2020 at 9:07 PM David Fetter wrote:
> On Sun, Dec 27, 2020 at 09:53:13AM -0800, Zhihong Yu wrote:
> > This is not an ideal way to index multirages, but something we can
> > easily have.
>
> What sort of indexing improvements do you have in mind?
Approximation of multirange as a ra
On Sun, Dec 27, 2020 at 8:52 PM Zhihong Yu wrote:
> This is not an ideal way to index multirages, but something we can easily
> have.
>
> typo: multiranges
Thanks for catching. I will revise the commit message before committing.
--
Regards,
Alexander Korotkov
On Sun, Dec 27, 2020 at 09:53:13AM -0800, Zhihong Yu wrote:
> Hi,
>
> This is not an ideal way to index multirages, but something we can
> easily have.
What sort of indexing improvements do you have in mind?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vo
Hi,
This is not an ideal way to index multirages, but something we can easily
have.
typo: multiranges
Cheers
On Sun, Dec 27, 2020 at 1:50 AM Alexander Korotkov
wrote:
> On Thu, Dec 17, 2020 at 10:10 PM Alexander Korotkov
> wrote:
> >
> > I think this patch is very close to committable. I'm
On Thu, Dec 17, 2020 at 10:10 PM Alexander Korotkov
wrote:
>
> I think this patch is very close to committable. I'm going to spend
> some more time further polishing it and commit (if I don't find a
> major issue or face objections).
The main patch is committed. I've prepared a set of improveme
On Thu, Dec 17, 2020 at 2:37 AM Zhihong Yu wrote:
> Letting user manually name the multirange (after a few automatic attempts)
> seems reasonable.
Accepted. Thank you for your feedback.
--
Regards,
Alexander Korotkov
Letting user manually name the multirange (after a few automatic attempts)
seems reasonable.
Cheers
On Wed, Dec 16, 2020 at 3:34 PM Alexander Korotkov
wrote:
> On Thu, Dec 17, 2020 at 1:03 AM Alexander Korotkov
> wrote:
> > On Thu, Dec 17, 2020 at 12:54 AM Zhihong Yu wrote:
> > > +* The i
On Thu, Dec 17, 2020 at 1:03 AM Alexander Korotkov wrote:
> On Thu, Dec 17, 2020 at 12:54 AM Zhihong Yu wrote:
> > +* The idea is to prepend underscores as needed until we make a name
> > that
> > +* doesn't collide with anything ...
> >
> > I wonder if other characters (e.g. [a-z0-9]) c
On Thu, Dec 17, 2020 at 12:54 AM Zhihong Yu wrote:
> +* The idea is to prepend underscores as needed until we make a name that
> +* doesn't collide with anything ...
>
> I wonder if other characters (e.g. [a-z0-9]) can be used so that name without
> collision can be found without calling
Hi,
w.r.t. patch v27.
+* The idea is to prepend underscores as needed until we make a name
that
+* doesn't collide with anything ...
I wonder if other characters (e.g. [a-z0-9]) can be used so that name
without collision can be found without calling truncate_identifier().
+ else if
On 2020-Dec-08, Alexander Korotkov wrote:
> I also found a problem in multirange types naming logic. Consider the
> following example.
>
> create type a_multirange AS (x float, y float);
> create type a as range(subtype=text, collation="C");
> create table tbl (x __a_multirange);
> drop type a_m
On Mon, Nov 30, 2020 at 11:39 PM Alexander Korotkov
wrote:
> On Mon, Nov 30, 2020 at 10:35 PM Alexander Korotkov
> wrote:
> > On Sun, Nov 29, 2020 at 11:53 PM Paul A Jungwirth
> > wrote:
> > >
> > > On Sun, Nov 29, 2020 at 11:43 AM Alexander Korotkov
> > > wrote:
> > > > Thank you. Could you p
On Mon, Nov 30, 2020 at 10:35 PM Alexander Korotkov
wrote:
> On Sun, Nov 29, 2020 at 11:53 PM Paul A Jungwirth
> wrote:
> >
> > On Sun, Nov 29, 2020 at 11:43 AM Alexander Korotkov
> > wrote:
> > > Thank you. Could you please, update doc/src/sgml/catalogs.sgml,
> > > because pg_type and pg_range
On Sun, Nov 29, 2020 at 11:53 PM Paul A Jungwirth
wrote:
>
> On Sun, Nov 29, 2020 at 11:43 AM Alexander Korotkov
> wrote:
> > Thank you. Could you please, update doc/src/sgml/catalogs.sgml,
> > because pg_type and pg_range catalogs are updated.
>
> Attached! :-)
You're quick, thank you. Please
On Sun, Nov 29, 2020 at 8:11 PM Paul A Jungwirth
wrote:
> On Fri, Nov 27, 2020 at 12:35 AM Alexander Korotkov
> wrote:
> > I'd like to review this patch. Could you please rebase it once again?
> > Thanks.
>
> Thanks! Here is a rebased version. It also includes one more cleanup
> commit from Al
Hi!
On Thu, Sep 24, 2020 at 3:05 AM Paul A Jungwirth
wrote:
> On Sun, Aug 16, 2020 at 12:55 PM Paul A Jungwirth
> wrote:
> > This is rebased on the current master, including some changes to doc
> > tables and pg_upgrade handling of type oids.
>
> Here is a rebased version of this patch, includin
čt 24. 9. 2020 v 2:05 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Sun, Aug 16, 2020 at 12:55 PM Paul A Jungwirth
> wrote:
> > This is rebased on the current master, including some changes to doc
> > tables and pg_upgrade handling of type oids.
>
> Here is a rebased v
On Sun, Jul 5, 2020 at 12:11 PM Paul A Jungwirth
wrote:
>
> Just knowing that arrays are
> something we do this for is enough to hunt for clues, but if anyone
> can point me more directly to code that will help me do it for
> multiranges, I'd be appreciative.
It looks like expandeddatum.h is wher
On Sat, Apr 11, 2020 at 09:36:37AM -0700, Paul A Jungwirth wrote:
> On Fri, Apr 10, 2020 at 8:44 PM Paul A Jungwirth
> wrote:
> > Thanks, and thanks for your v17 also. Here is a patch building on that
> > and adding support for anycompatiblemultirange.
>
> Here is a v19 that just moved the multi
On 2020-Apr-11, Paul A Jungwirth wrote:
> On Sat, Apr 11, 2020 at 9:36 AM Paul A Jungwirth
> wrote:
> > Btw I'm working on typanalyze + selectivity, and it seems like the
> > test suite doesn't run those things?
>
> Nevermind, I just had to add `analyze numrange_test` to
> src/test/regress/sql/r
On Sat, Apr 11, 2020 at 9:36 AM Paul A Jungwirth
wrote:
> Btw I'm working on typanalyze + selectivity, and it seems like the
> test suite doesn't run those things?
Nevermind, I just had to add `analyze numrange_test` to
src/test/regress/sql/rangetypes.sql. :-) Do you want a separate patch
for tha
v17 is a rebase fixing a minor parse_coerce.c edit; v16 lasted little
:-( I chose to change the wording of the conflicting comment in
enforce_generic_type_consistency():
* 3) Similarly, if return type is ANYRANGE or ANYMULTIRANGE, and any
*argument is ANYRANGE or ANYMULTIRANGE, use that
Thanks Alvaro!
On Mon, Mar 23, 2020 at 4:33 PM Alvaro Herrera
wrote:
>
> Thinking about the on-disk representation, can we do better than putting
> the contained ranges in long-varlena format, including padding; also we
> include the type OID with each element. Sounds wasteful. A more
> comp
On 2020-Mar-19, Paul A Jungwirth wrote:
> On Thu, Mar 19, 2020 at 1:43 PM Paul A Jungwirth
> wrote:
> > On Thu, Mar 19, 2020 at 1:42 PM Alvaro Herrera
> > wrote:
> > > There's been another flurry of commits in the polymorphic types area.
> > > Can you please rebase again?
> >
> > I noticed that
On 2020-Mar-14, Paul A Jungwirth wrote:
> On Fri, Mar 13, 2020 at 2:39 PM Alvaro Herrera
> wrote:
> > Here's the rebased version.
> >
> > I just realized I didn't include the API change I proposed in
> > https://postgr.es/m/20200306200343.GA625@alvherre.pgsql ...
>
> Thanks for your help with t
On Thu, Mar 19, 2020 at 1:42 PM Alvaro Herrera wrote:
>
> On 2020-Mar-16, Paul A Jungwirth wrote:
>
> > On Sat, Mar 14, 2020 at 11:13 AM Paul A Jungwirth
> > wrote:
> > > I think that should fix the cfbot failure.
> >
> > I saw this patch was failing to apply again. There was some
> > refactoring
On 2020-Mar-16, Paul A Jungwirth wrote:
> On Sat, Mar 14, 2020 at 11:13 AM Paul A Jungwirth
> wrote:
> > I think that should fix the cfbot failure.
>
> I saw this patch was failing to apply again. There was some
> refactoring to how polymorphic types are determined. I added my
> changes for anym
On Fri, Mar 13, 2020 at 2:39 PM Alvaro Herrera wrote:
> Here's the rebased version.
>
> I just realized I didn't include the API change I proposed in
> https://postgr.es/m/20200306200343.GA625@alvherre.pgsql ...
Thanks for your help with this Alvaro!
I was just adding your changes to my own bran
Paul A Jungwirth writes:
> On Wed, Mar 11, 2020 at 4:39 PM Paul A Jungwirth
> wrote:
>> Oh, my last email left out the most important part. :-) Is this
>> failure online somewhere so I can take a look at it and fix it?
Look for your patch(es) at
http://commitfest.cputube.org
Right now it's not
On Wed, Mar 11, 2020 at 4:39 PM Paul A Jungwirth
wrote:
>
> On Sat, Mar 7, 2020 at 12:20 PM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > [ v11 patches ]
> > The cfbot isn't too happy with this; it's getting differently-ordered
> > results than you apparently did for the list of owned objects
On Thu, Mar 12, 2020 at 5:38 AM Alvaro Herrera wrote:
> ... thinking about gist+spgist, I think they could be written
> identically to those for ranges, using the lowest (first) lower bound
> and the higher (last) upper bound.
>
> ... thinking about selectivity, I think the way to write that is to
Hello Paul, thanks for the thorough response to all these points.
Regarding the merge of multiranges with ranges, I had also thought of
that at some point and was leaning towards doing that, but after the
latest responses I think the arguments against it are sensible; and now
there's a clear maj
of the motivations to building a multirange type instead of
just using an array of ranges. Mathematically {[1,2), [2,3)} is
equivalent to {[1,3)}, and merging the touching elements keeps things
easier to read/understand and faster. Ranges themselves have a
canonical form too. Not canonicalizing raise
On Mon, Mar 09, 2020 at 06:34:04PM -0700, Jeff Davis wrote:
> On Sat, 2020-03-07 at 16:06 -0500, Tom Lane wrote:
> > Actually ... have you given any thought to just deciding that ranges
> > and
> > multiranges are the same type?
>
> It has come up in a number of conversations, but I'm not sure if
On Sat, 2020-03-07 at 16:06 -0500, Tom Lane wrote:
> Actually ... have you given any thought to just deciding that ranges
> and
> multiranges are the same type?
It has come up in a number of conversations, but I'm not sure if it was
discussed on this list.
> I think on the whole the advantages w
Alvaro Herrera writes:
> I wonder what's the point of multirange arrays. Is there a reason we
> create those?
That's what we thought about arrays of composites to start with,
too.
regards, tom lane
I wonder what's the point of multirange arrays. Is there a reason we
create those?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Mar 7, 2020 at 4:06 PM Tom Lane wrote:
> It's possible that this is a bad idea. It bears a lot of similarity,
> I guess, to the way that Postgres doesn't consider arrays of different
> dimensionality to be distinct types. That has some advantages but it
> surely also has downsides. I th
On Fri, Dec 20, 2019 at 10:43 AM Alvaro Herrera
wrote:
> I took the liberty of rebasing this series on top of recent branch
> master.
>
In the tests there is:
+select '{[a,a],[b,b]}'::textmultirange;
+ textmultirange
+
+ {[a,a],[b,b]}
+(1 row)
+
+-- without canonicalization, we
Isaac Morland writes:
>> so 7. 3. 2020 v 22:20 odesílatel Tom Lane napsal:
>>> Actually ... have you given any thought to just deciding that ranges and
>>> multiranges are the same type? That is, any range can now potentially
>>> contain multiple segments?
> Definitely agreed that range and mul
d if I
accidentally try to take the union of ranges where the union isn’t another
range, I want to get an error rather than calculate some weird (in my
context) multirange.
On a related note, I was thinking about this and I don’t think I like
range_agg as a name at all. I know we have array_
On Sat, Mar 07, 2020 at 06:45:44PM -0500, Tom Lane wrote:
> David Fetter writes:
> > There's another use case not yet covered here that could make this
> > even more complex, we should probably plan for it: multi-ranges
> > with weights.
>
> I'm inclined to reject that as completely out of scope.
David Fetter writes:
> There's another use case not yet covered here that could make this
> even more complex, we should probably plan for it: multi-ranges with
> weights.
I'm inclined to reject that as completely out of scope. The core
argument for unifying multiranges with ranges, if you ask m
On Sat, Mar 07, 2020 at 04:06:32PM -0500, Tom Lane wrote:
> I wrote:
> > However, what I'm on about right at the moment is that I don't think
> > there should be any delta in that test at all. As far as I can see,
> > the design idea here is that multiranges will be automatically created
> > over
so 7. 3. 2020 v 22:20 odesílatel Tom Lane napsal:
> I wrote:
> > Actually ... have you given any thought to just deciding that ranges and
> > multiranges are the same type? That is, any range can now potentially
> > contain multiple segments? That would eliminate a whole lot of the
> > tedious
I wrote:
> Actually ... have you given any thought to just deciding that ranges and
> multiranges are the same type? That is, any range can now potentially
> contain multiple segments? That would eliminate a whole lot of the
> tedious infrastructure hacking involved in this patch, and let you foc
I wrote:
> However, what I'm on about right at the moment is that I don't think
> there should be any delta in that test at all. As far as I can see,
> the design idea here is that multiranges will be automatically created
> over range types, and the user doesn't need to do that. To my mind,
> th
Alvaro Herrera writes:
> [ v11 patches ]
The cfbot isn't too happy with this; it's getting differently-ordered
results than you apparently did for the list of owned objects in
dependency.out's DROP OWNED BY test. Not sure why that should be ---
it seems like af6550d34 should have ensured that th
Thanks for looking at this again!
On 3/4/20 1:33 PM, Alvaro Herrera wrote:
I came across an interesting thing, namely multirange_canonicalize()'s
use of qsort_arg with a callback of range_compare(). range_compare()
calls range_deserialize() (non-trivial parsing) for each input range;
multirange
I came across an interesting thing, namely multirange_canonicalize()'s
use of qsort_arg with a callback of range_compare(). range_compare()
calls range_deserialize() (non-trivial parsing) for each input range;
multirange_canonicalize() later does a few extra deserialize calls of
its own. Call me
Hi
st 22. 1. 2020 v 0:55 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Sun, Jan 19, 2020 at 9:57 PM Paul A Jungwirth
> wrote:
> > On Sun, Jan 19, 2020 at 4:38 PM Tom Lane wrote:
> > > True for casts involving concrete types, mainly because we'd like
> > > the identit
On Sun, Jan 19, 2020 at 4:38 PM Tom Lane 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
po 20. 1. 2020 v 1:38 odesílatel Tom Lane napsal:
> Paul A Jungwirth writes:
> > On Sun, Jan 19, 2020 at 12:10 AM Pavel Stehule
> 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 an
Paul A Jungwirth writes:
> On Sun, Jan 19, 2020 at 12:10 AM Pavel Stehule
> 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 ca
On Sun, Jan 19, 2020 at 12:10 AM Pavel Stehule 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
so 18. 1. 2020 v 17:35 odesílatel Pavel Stehule
napsal:
>
>
> so 18. 1. 2020 v 17:07 odesílatel Paul A Jungwirth <
> p...@illuminatedcomputing.com> napsal:
>
>> On Sat, Jan 18, 2020 at 7:20 AM Pavel Stehule
>> wrote:
>> > Can be nice to have a polymorphic function
>> >
>> > multirange(anymultira
so 18. 1. 2020 v 17:07 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Sat, Jan 18, 2020 at 7:20 AM Pavel Stehule
> wrote:
> > Can be nice to have a polymorphic function
> >
> > multirange(anymultirange, anyrange) returns anymultirange. This
> functions should to do mult
On Sat, Jan 18, 2020 at 7:20 AM Pavel Stehule wrote:
> Can be nice to have a polymorphic function
>
> multirange(anymultirange, anyrange) returns anymultirange. This functions
> should to do multirange from $2 to type $1
>
> It can enhance to using polymorphic types and simplify casting.
Thanks
pá 17. 1. 2020 v 21:08 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Fri, Jan 10, 2020 at 1:38 AM Pavel Stehule
> wrote:
> >> This still leaves the question of how best to format the docs for
> >> these operators. I like being able to combine all the <@ variations
> >>
Hi
so 4. 1. 2020 v 6:29 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Fri, Dec 20, 2019 at 11:29 AM Alvaro Herrera
> wrote:
> > > Should I just give up on implicit casts and require you to specify
> > > one? That makes it a little more annoying to mix range & multiran
Alvaro Herrera writes:
> On 2019-Dec-20, Paul A Jungwirth wrote:
>> Is it permitted to add casts with polymorphic inputs & outputs? Is
>> that something that we would actually want to do? I'd probably need
>> both the polymorphic and concrete casts so that you could still say
>> `int4range(1,2)::i
On 2019-Dec-20, Paul A Jungwirth wrote:
> Is it permitted to add casts with polymorphic inputs & outputs? Is
> that something that we would actually want to do? I'd probably need
> both the polymorphic and concrete casts so that you could still say
> `int4range(1,2)::int4multirange`.
I'm embarras
On Fri, Dec 20, 2019 at 10:19 AM Pavel Stehule wrote:
> I had a talk with Paul about possible simplification of designed operators.
> Last message from Paul was - he is working on new version.
Thanks Alvaro & Pavel for helping move this forward. I've added the
casts but they aren't used automati
On 2019-Dec-20, Alvaro Herrera wrote:
> I am not convinced that adding TYPTYPE_MULTIRANGE is really necessary.
> Why can't we just treat those types as TYPTYPE_RANGE and distinguish
> them using TYPCATEGORY_MULTIRANGE? That's what we do for arrays. I'll
> try to do that next.
I think this can b
pá 20. 12. 2019 v 18:43 odesílatel Alvaro Herrera
napsal:
> I took the liberty of rebasing this series on top of recent branch
> master. The first four are mostly Paul's originals, except for conflict
> fixes; the rest are changes I'm proposing as I go along figuring out the
> whole thing. (I w
Hi Paul
I'm starting to look at this again. Here's a few proposed changes to
the current code as I read along.
I noticed that 0001 does not compile on its own. It works as soon as I
add 0002. What this is telling me is that the current patch split is
not serving any goals; I think it's okay to
pá 22. 11. 2019 v 17:25 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Thu, Nov 21, 2019 at 9:21 PM Pavel Stehule
> wrote:
> > I though about it, and I think so cast from multirange to range is
> useless, minimally it should be explicit.
>
> I agree: definitely not impl
On Thu, Nov 21, 2019 at 9:21 PM Pavel Stehule wrote:
> I though about it, and I think so cast from multirange to range is useless,
> minimally it should be explicit.
I agree: definitely not implicit. If I think of a good reason for it
I'll add it, but otherwise I'll leave it out.
> On second ha
čt 21. 11. 2019 v 21:15 odesílatel Paul Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On 11/21/19 1:06 AM, Pavel Stehule wrote:
> > 2. I don't like introduction "safe" operators - now the basic operators
> > are doubled, and nobody without documentation will use @* operators.
> >
> > It is
On 11/21/19 1:06 AM, Pavel Stehule wrote:
2. I don't like introduction "safe" operators - now the basic operators
are doubled, and nobody without documentation will use @* operators.
It is not intuitive. I think is better to map this functionality to
basic operators +- * and implement it just
st 20. 11. 2019 v 20:32 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Tue, Nov 19, 2019 at 9:49 PM Paul A Jungwirth
> wrote:
> >
> > On Tue, Nov 19, 2019 at 1:17 AM Pavel Stehule
> wrote:
> > > Hi
> > > I tested last patches. I found some issues
> >
> > Thank you for
On Tue, Nov 19, 2019 at 1:17 AM Pavel Stehule wrote:
> Hi
> I tested last patches. I found some issues
Thank you for the review!
> 1. you should not to try patch catversion.
I've seen discussion on pgsql-hackers going both ways, but I'll leave
it out of future patches. :-)
> 2. there is warnin
Hi
čt 7. 11. 2019 v 3:36 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Wed, Nov 6, 2019 at 3:02 PM Paul A Jungwirth
> wrote:
> > On Thu, Sep 26, 2019 at 2:13 PM Alvaro Herrera
> wrote:
> > > Hello Paul, I've started to review this patch. Here's a few minor
> > > thi
Hello Paul, I've started to review this patch. Here's a few minor
things I ran across -- mostly compiler warnings (is my compiler too
ancient?). You don't have to agree with every fix -- feel free to use
different fixes if you have them. Also, feel free to squash them onto
whatever commit you li
On Thu, 2019-09-05 at 10:45 -0700, Paul A Jungwirth wrote:
> Right now I'm planning to do all that before sending a patch. I'm
> happy to send something something in-progress too, but I don't want
> to
> waste any reviewers' time. If folks want an early peak though let me
> know. (You can also find
there any reason to send a "preview" patch with my current
progress, since we're starting a new commit fest? Here is what I have
left to do:
- Change those three operators.
- Write range_intersect_agg. (range_agg is done but needs some tests
before I commit it.)
- Write documenta
On Sun, 2019-09-01 at 06:26 -0700, Paul A Jungwirth wrote:
> @+ and @- and @* (I dunno why but I kind of like it. We already have
> @> and <@.)
I think I like this proposal best; it reminds me of perl. Though some
might say that's an argument against it.
Regards,
Jeff Davis
> > Btw I have working multirange_{send,recv,in,out} now. . . .
Just about all the other operators are done too, but I wonder what
symbols people like for union and minus? Range uses + for union. I
have working code and tests that adds this:
r + mr = mr
mr + r = mr
mr + mr = mr
But I would like
On Wed, 2019-08-21 at 21:54 -0700, Paul A Jungwirth wrote:
> Sometimes I think about having a maybe type instead of null/not
> null. SQL nulls are already very "monadic" I think but nullability
> doesn't travel.
Yeah, that would be a great direction, but there is some additional
complexity that we
On Tue, Aug 20, 2019 at 10:33 PM Jeff Davis wrote:
> > Is there any historical discussion around
> > typemods on range types?
>
> I did find a few references:
Thanks for looking those up! It's very interesting to see some of the
original discussion around range types.
Btw this is true of so much
On Sat, 2019-08-17 at 10:47 -0700, Paul A Jungwirth wrote:
> So I'm wondering how seriously I should take this for multiranges? I
> guess if a range type did support typmods, it would just delegate to
> the underlying element type for their meaning, and so a multirange
> should delegate it too? Is
On Mon, Jul 8, 2019 at 9:46 AM Paul A Jungwirth
wrote:
> - A multirange type is an extra thing you get when you define a range
> (just like how you get a tstzrange[]). Therefore
I've been able to make a little more progress on multiranges the last
few days, but it reminded me of an open quest
On Wed, Jul 24, 2019 at 5:13 PM Paul A Jungwirth
wrote:
> On Tue, Jul 23, 2019 at 3:32 PM Alvaro Herrera
> wrote:
> > Just checking if you've had a chance to make progress on this.
>
> Not a lot. :-) But I should have more time for it the next few weeks
> than I did the last few. ...
Hi Paul,
On Tue, Jul 23, 2019 at 3:32 PM Alvaro Herrera wrote:
> Just checking if you've had a chance to make progress on this.
Not a lot. :-) But I should have more time for it the next few weeks
than I did the last few. I do have some code for creating concrete
multirange types (used when you create a c
Hi Paul,
Just checking if you've had a chance to make progress on this.
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 7/9/19 11:24 PM, David Fetter wrote:
I seem to recall that the usual convention (at least in math) is
to use intervals that are generally represented as open on the
infinity side, but that might not fit how we do things.
I think it does, unless I'm misunderstanding?
Oh, I was just wonderin
On Tue, Jul 09, 2019 at 09:40:59AM -0700, Paul A Jungwirth wrote:
> On Tue, Jul 9, 2019 at 8:51 AM David Fetter wrote:
> > > - A multirange type is an extra thing you get when you define a range
> > > (just like how you get a tstzrange[]). Therefore
> > > - I don't need separate commands to ad
st 10. 7. 2019 v 6:26 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Tue, Jul 9, 2019 at 12:24 PM Pavel Stehule
> wrote:
> > út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule
> napsal:
> >> I afraid so with generic multiragetype there lot of array
> infrastructure will be
On Tue, Jul 9, 2019 at 12:24 PM Pavel Stehule wrote:
> út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule
> napsal:
>> I afraid so with generic multiragetype there lot of array infrastructure
>> will be duplicated
>
> on second hand - it is true so classic array concat is not optimal for set of
>
On Tue, Jul 9, 2019 at 12:02 PM Jeff Davis wrote:
> > - Multirange in/out work just like arrays, e.g. '{"[1,3)", "[5,6)"}'
>
> It would be cool to have a better text representation. We could go
> simple like:
>
>'[1,3) [5,6)'
Will that work with all ranges, even user-defined ones? With a
tstz
1 - 100 of 136 matches
Mail list logo
