Em qua., 10 de set. de 2025 às 13:59, Dean Rasheed
escreveu:
> Agreed. I think something like the attached ought to be sufficient.
>
> Yeap, this way is fine.
regards
Marcos
On Wed, 10 Sept 2025 at 14:30, Marcos Pegoraro wrote:
>
> This patch adds functions func-datetime.sgml but those functions depend on
> setseed function, which is not there.
> Wouldn't it be good to add a note that setseed() will change the result of
> those random functions ?
Agreed. I think so
Em ter., 9 de set. de 2025 às 07:00, Dean Rasheed
escreveu:
> On Mon, 8 Sept 2025 at 13:40, Dean Rasheed
> wrote:
> Committed.
>
This patch adds functions func-datetime.sgml but those functions depend on
setseed function, which is not there.
Wouldn't it be good to add a note that setseed() will
On Tue, 26 Aug 2025 at 15:17, Damien Clochard wrote:
>
> Le 25.08.2025 15:33, Greg Sabino Mullane a écrit :
> > Your v3 did not get attached to the previous email.
>
> My bad, here it is
It seems like we have reached a consensus on adding just the random
date and timestamp[tz] functions, so I too
On Mon, 8 Sept 2025 at 13:40, Dean Rasheed wrote:
>
> I think this is now committable, so if there are no objections, I'll
> push this shortly.
Committed.
Regards,
Dean
Vik Fearing writes:
> On 29/08/2025 11:12, Chao Li wrote:
>> But a major problem is, I think we should bump CATALOG_VERSION_NO.
> Traditionally, the patch committer bumps the catversion, not the patch
> author.
Yeah. If you include a catversion bump in a submitted patch, you can
expect the pa
On 29/08/2025 11:12, Chao Li wrote:
On Aug 26, 2025, at 22:17, Damien Clochard wrote:
Le 25.08.2025 15:33, Greg Sabino Mullane a écrit :
Your v3 did not get attached to the previous email.
My bad, here it is
--
Damien
Clochard
Code change looks good to me. Maybe we can make
check_ra
> On Aug 26, 2025, at 22:17, Damien Clochard wrote:
>
> Le 25.08.2025 15:33, Greg Sabino Mullane a écrit :
>> Your v3 did not get attached to the previous email.
>
> My bad, here it is
>
> --
> Damien
> Clochard
Code change looks good to me. Maybe we can make check_range_boundaries()
“inl
Patch looks good
On Mon, 25 Aug 2025 at 12:42, Damien Clochard wrote:
>
> Note that former random function variants are documented in
> func/func-math.sgml but it felt more logical to document the new
> variants in func-datetime.sgml. As a result the random variants would be
> documented in 2 separate sections of
Le 25.08.2025 15:33, Greg Sabino Mullane a écrit :
Your v3 did not get attached to the previous email.
My bad, here it is
--
Damien ClochardFrom 046deb02a7a1d468ff90b714e3fdcba29f865c3b Mon Sep 17 00:00:00 2001
From: damien
Date: Thu, 3 Jul 2025 13:13:30 +
Subject: [PATCH v3 2/2] Generate
Your v3 did not get attached to the previous email.
Le 24.07.2025 20:24, Vik Fearing a écrit :
[...]
Just a small cosmetic gripe, the regression test comments are usually
"-- ok" and "--fail", and not "-- Should error".
Thanks Vik!
Here's a third version with the following changes:
* Rebase from master
* Replace 'Should error' by 'fail' in
On 24/07/2025 17:20, Damien Clochard wrote:
Le 21.07.2025 21:06, Greg Sabino Mullane a écrit :
Damien, maybe we can let the time ones go? Tom and I are not big fans
of those, and nobody else has stepped up to defend them.
Here's a second version with the following changes
- update tests
Le 21.07.2025 21:06, Greg Sabino Mullane a écrit :
Damien, maybe we can let the time ones go? Tom and I are not big fans
of those, and nobody else has stepped up to defend them.
Sure !
Here's a second version with the following changes
- remove time and timetz variants
- disallow infinity bo
Damien, maybe we can let the time ones go? Tom and I are not big fans of
those, and nobody else has stepped up to defend them.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
Greg Sabino Mullane writes:
> On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed
> wrote:
>> Is it really worth adding a core function for that?
> Yes, I think it is. It is also trivial to get a random int from 50 to 100
> with
> 50 + floor(random() * 51)
> but random(50,100) is so much nicer.
I won'
On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed
wrote:
> But it's completely trivial to emulate random(min_date, max_date), just by
> doing
>
> min_date + random(0, max_date - min_date)
>
> Is it really worth adding a core function for that?
>
Yes, I think it is. It is also trivial to get a rando
On Tue, 15 Jul 2025 at 04:49, Robert Treat wrote:
>
> On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed wrote:
> >
> > But it's completely trivial to emulate random(min_date, max_date), just by
> > doing
> >
> > min_date + random(0, max_date - min_date)
> >
> > Is it really worth adding a core func
On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed wrote:
> On Sat, 12 Jul 2025 at 16:15, Greg Sabino Mullane wrote:
> >
> > I like the idea, especially the date variant. Unlike Tom, I'm not
> > particularly concerned about breakage of existing scripts, as
> > most already are working just fine with r
On Sat, 12 Jul 2025 at 16:15, Greg Sabino Mullane wrote:
>
> I like the idea, especially the date variant. Unlike Tom, I'm not
> particularly concerned about breakage of existing scripts, as
> most already are working just fine with raw numbers and I don't see this
> patch breaking them.
>
> In
Patch review
OVERALL:
I like the idea, especially the date variant. Unlike Tom, I'm not
particularly concerned about breakage of existing scripts, as
most already are working just fine with raw numbers and I don't see this
patch breaking them.
In a selfish vein, I would use the "date" and timest
Le 10.07.2025 00:14, Tom Lane a écrit :
Damien Clochard writes:
So this adds 5 new variants of the random() function:
random(min date, max date) returns date
random(min time, max time) returns time
random(min time, max time, zone text) returns timetz
random(min timestamp,
Damien Clochard writes:
> So this adds 5 new variants of the random() function:
> random(min date, max date) returns date
> random(min time, max time) returns time
> random(min time, max time, zone text) returns timetz
> random(min timestamp, max timestamp) returns timestamp
>
24 matches
Mail list logo
