o tip the scales against it, but still a demerit.
I don't really want such a patch. I use new psql on old servers all the
time.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 01/12/2018 06:59 AM, Edmund Horner wrote:
> Hi, here's a new patch.
Thanks, and sorry for the delay. I have reviewed this patch, but
haven't had time to put my thoughts together in a coherent message yet.
I will be able to do that tomorrow.
Thank you for your patience.
--
Matches1, you miss cases like
this: SELECT (SELECT
It also occurred to me that SELECT isn't actually a complete command (or
whatever you want to call it), it's an abbreviation for SELECT ALL. So
you should check for SELECT, SELECT ALL, and SELECT DISTINCT. (The FROM
tab comple
On Tue, Jan 23, 2018 at 4:17 AM, Edmund Horner wrote:
> Hi Vik, thanks for the feedback!
>
Don't forget to include the list :-)
I'm quoting the entirety of the message---which I would normally trim---for
the archives.
> On 23 January 2018 at 07:41, Vik Fearing
> wrote:
While reviewing the patch for tab completion after SELECT, I realized
that psql doesn't know how to complete after FROM if the ONLY keyword is
present.
This trivial patch fixes that, as well as JOIN ONLY and TABLE ONLY.
--
Vik Fearing +33 6 46 75
;
test'# quit
Use \q to quit or press control-C to clear the input buffer.
test'# \q
test'#
Surely that's not helpful.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 01/26/2018 01:28 AM, Edmund Horner wrote:
> On 19 January 2018 at 05:37, Vik Fearing wrote:
>> On 01/18/2018 01:07 AM, Tom Lane wrote:
>>> Edmund Horner writes:
>>>> On 15 January 2018 at 15:45, Andres Freund wrote:
>>>>> All worries like
user is
interested in the short forms, they can issue a \? like everybody else.
> In additional to aiding tab completion discovery of the commands (i.e.
> typing "\desc" and then hitting tab, it would also make scripts a little
> more self-documenting.
I
On 01/26/2018 03:49 PM, David Fetter wrote:
> I propose that we do what at least MySQL, Oracle, and DB2 do and
> implement DESCRIBE as its own command.
Hard pass.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, For
On 01/27/2018 05:39 PM, David Fetter wrote:
> On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:
>> On 01/26/2018 03:49 PM, David Fetter wrote:
>>> I propose that we do what at least MySQL, Oracle, and DB2 do and
>>> implement DESCRIBE as its own command.
>
On 28/10/2019 13:48, Surafel Temesgen wrote:
>
>
> On Fri, Oct 25, 2019 at 10:45 PM Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> >
> > I don't understand what you mean by this.
> >
> >
> >
> >
this by allowing an alias on
the join clause. ( in section 7.10)
SELECT j.x, j.y, j.z FROM a INNER JOIN b USING (z) AS j;
Attached is a patch (based on 517bf2d910) adding this feature.
--
Vik Fearing
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index 22252556be
On 29/10/2019 12:05, Peter Eisentraut wrote:
> On 2019-10-29 11:47, Vik Fearing wrote:
>> When joining tables with USING, the listed columns are merged and no
>> longer belong to either the left or the right side. That means they can
>> no longer be qualified which can ofte
On 29/10/2019 12:24, Isaac Morland wrote:
> If you need to refer specifically to the non-qualified version in a
> different part of the query, you can give an alias to the result of
> the join:
>
> ... (a join b using (z)) as t ...
Yes, this is about having standard SQL syntax for that.
On 29/10/2019 15:20, Tom Lane wrote:
> Vik Fearing writes:
>> On 29/10/2019 12:24, Isaac Morland wrote:
>>> If you need to refer specifically to the non-qualified version in a
>>> different part of the query, you can give an alias to the result of
>>> the joi
On 30/10/2019 09:04, Fabien COELHO wrote:
>
>> I think possibly what the spec says (and that neither my patch nor
>> Peter's implements) is assigning the alias just to the > list>.
>
> I think you are right, the alias is only on the identical columns.
>
> It solves the issue I raised about inacces
ctions
>> I'll send a patch.
> If we do this, cluster_name should be included in csvlog?
Yes, absolutely.
--
Vik Fearing
On 05/11/2019 02:45, Alexander Korotkov wrote:
> 3) Do we like to change behavior to_date()/to_timestamp()? Or just
> jsonpath .datetime() and future CAST(... AS ... FORMAT ...) defined in
> SQL 2016?
I don't want to hijack this thread, but I would like the CAST feature to
call to_timestamp() an
_vs_SQL_Standard
--
Vik Fearing
I recently came across the need for a gcd function (actually I needed
lcm) and was surprised that we didn't have one.
So here one is, using the basic Euclidean algorithm. I made one for
smallint, integer, and bigint.
--
Vik Fearing +33 6 46 75
commit
94cd0f1ad8a.
Adding another keyword can break backwards compatibility, of course. So
that is an issue that needs to be discussed, but I don't imagine too
many people are using role names "superuser" and "nonsuperuser". Those
who are will have to quot
On 28/12/2019 19:07, Tom Lane wrote:
> Vik Fearing writes:
>> It can sometimes be useful to match against a superuser in pg_hba.conf.
> Seems like a reasonable desire.
>
>> Adding another keyword can break backwards compatibility, of course. So
>> that is an issue that
On 28/12/2019 19:15, Fabien COELHO wrote:
>
>> So here one is, using the basic Euclidean algorithm. I made one for
>> smallint, integer, and bigint.
>
> Should pg provide the LCM as well? Hmmm, probably not, too likely to
> overflow.
I decided against it for that reason.
> Should there be a NU
On 29/12/2019 08:30, Fabien COELHO wrote:
>
>>> I'm wondering what it should do on N, 0 and 0, 0. Raise an error?
>>> Return 0? Return 1? return N? There should be some logic and comments
>>> explaining it.
>>
>> Well, gcd(N, 0) is N, and gcd(0, 0) is 0, so I don't see an issue here?
>
> I think th
On 29/12/2019 17:31, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
>> wrote:
>>> I'm all for this (and even suggested it during the IRC conversation that
>>> prompted this patch). It's rife with bikeshedding, t
On 29/12/2019 23:10, Vik Fearing wrote:
> On 29/12/2019 17:31, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
>>> wrote:
>>>> I'm all for this (and even suggested it during the IRC conversation that
>>&g
this, Peter.
One thing I notice is that the joined columns are still accessible from
their respective table names when they should not be per spec. That
might be one of those "silly restrictions" that we choose to ignore, but
it should probably be noted somewhere, at the very least in a code
comment if not in user documentation. (This is my reading of SQL:2016 SR
11.a.i)
--
Vik Fearing
On 01/01/2020 11:50, Surafel Temesgen wrote:
>
>
> Hi,
> Attached is a complete patch and also contain a fix for your comments
>
This does not compile against current head (0ce38730ac).
gram.y: error: shift/reduce conflicts: 6 found, 0 expected
--
Vik Fearing
On 02/01/2020 20:52, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 29/12/2019 23:10, Vik Fearing wrote:
>>> On 29/12/2019 17:31, Tom Lane wrote:
>>>> Robert Haas writes:
>>>>> On Sat, Dec 28, 20
On 03/01/2020 11:57, Surafel Temesgen wrote:
>
>
> On Thu, Jan 2, 2020 at 12:12 AM Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> This does not compile against current head (0ce38730ac).
>
>
> gram.y: error: shift/reduce conflicts: 6 fo
ible. I made this choice because int2mul returns int2
(and same for its friends). One can just cast to a bigger integer if
needed.
Because of that, I added a version of gcd() and lcm() for numeric. This
was my first time working with numeric so reviewers should pay extra
attention there, please
#x27;m unsure about gcd(INT_MIN, 0) should error. Possibly 0 would be nicer?
What justification for that do you have?
--
Vik Fearing
On 04/01/2020 00:49, Tom Lane wrote:
> Vik Fearing writes:
>> On 03/01/2020 20:14, Fabien COELHO wrote:
>>> The point of swapping is to a void possibly expensive modulo, but this
>>> should be done on absolute values, otherwise it may not achieve its
>>> pur
On 04/01/2020 01:21, Tom Lane wrote:
> Vik Fearing writes:
>> On 03/01/2020 20:14, Fabien COELHO wrote:
>>> I'm unsure about gcd(INT_MIN, 0) should error. Possibly 0 would be nicer?
>> What justification for that do you have?
> Zero is the "correct" a
On 04/01/2020 01:26, Vik Fearing wrote:
> On 04/01/2020 01:21, Tom Lane wrote:
>> Vik Fearing writes:
>>> On 03/01/2020 20:14, Fabien COELHO wrote:
>>>> I'm unsure about gcd(INT_MIN, 0) should error. Possibly 0 would be nicer?
>>> What justification f
of swapping is to a void possibly expensive modulo, but this
> should be done on absolute values, otherwise it may not achieve its
> purpose as stated by the comment?
Here is an updated patch fixing that.
--
Vik Fearing
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
ind
, n \neq MIN_INT4, \gcd(n, 0) = 0 ?
>
> In which case applying the same rule for min int seems ok.
No, gcd(n, 0) = n.
--
Vik Fearing
truct inputs that take
>> minutes to compute, although this is admittedly with ridiculously
>> large inputs (~10^13), and AFAICS, the performance is OK with
>> "normal" sized inputs. Should we put a limit on the size of the
>> inputs?
> No, but a CHECK_FOR_
On 04/01/2020 20:08, Dean Rasheed wrote:
> On Sat, 4 Jan 2020 at 17:55, Vik Fearing wrote:
>> On 04/01/2020 10:37, Dean Rasheed wrote:
>>> BTW, there is actually no need to restrict the inputs to integral
>>> values because GCD is something that has a perfectly natura
On 05/01/2020 11:16, Surafel Temesgen wrote:
>
>
> On Fri, Jan 3, 2020 at 4:22 PM Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> >
> > Rebased and conflict resolved i hope it build clean this time
> >
>
> It does but
gt;>
>> select a from stest0 for system_time from '2000-01-01 00:00:00.0' to
>> 'infinity' ORDER BY a;
>>
>>
>> That is, the FOR should be on the other side of the table name.
>>
>> [...]
>>
>> Vik Fearing
> Hello,
On 06/01/2020 17:03, Tom Lane wrote:
> So it's not clear to me whether we have any meeting of the minds
> on wanting this patch. In the meantime, though, the cfbot
> reports that the patch breaks the ssl tests. Why is that?
I have no idea. I cannot reproduce the failure loca
On 05/01/2020 13:50, Vik Fearing wrote:
> Okay, now that I see your tests, I understand why everything is broken.
> You only test FROM-TO and with a really wide interval. There are no
> tests for AS OF and no tests for BETWEEN-AND.
I have started working on some better test cases for
ed names and rebased my original patch on top of it. Only
the docs changed in the rebase. The original patch (or its rebase) is
what I am interested in.
--
Vik Fearing
On 13/01/2020 15:19, Tom Lane wrote:
> Krasiyan Andreev writes:
>> I want to propose to you an old patch for Postgres 11, off-site developed
>> by Oliver Ford,
>> but I have permission from him to publish it and to continue it's
>> development,
>> that allow distinct aggregates, like select sum(di
It seems that PERCENT will be easily implemented on that.
>
> However, isn't there a possibility that we allow FETCH FIRST x PERCENT
> WITH TIES, though I'm not sure what SQL spec tells about that? I
> don't come up right now how to do that using window functions..
PERCENT and WITH TIES can play together, per spec.
--
Vik Fearing
is an int not a smallint.
>>
> I see this has been marked RFC. I'll take it,
Thanks!
> and barring objections,
> I'll start by ripping out the smallint code.
No strong objection.
--
Vik Fearing
In that case should lcm be "...that is an integral multiple..." since
the numeric version will return numeric?
Other than that, I'm happy with this change.
--
Vik Fearing
ll
already deal with the tables separately as needed, but I don't see when
a manual vacuum would want to make this distinction.
--
Vik Fearing
the copy,
> leaving the original NumericVar with a buf pointing to freed memory.
Thank you for taking the time to look closely at this. This was my
first time dealing with "numeric" so I was bound to make some mistakes.
--
Vik Fearing
I cannot ever think of a time when I don't want to know if I'm in a
transaction or not (and what its state is). Every new setup I do, I add
%x to the psql prompt.
I think it should be part of the default prompt. Path attached.
--
Vik Fearing
>From 6118b8b2ab4cfc70525666b8d57eaa3
nk it should be part of the default prompt. Path attached.
>
> Isn't there examples in the documentation which use the default prompts?
>
> If so, should they be updated accordingly?
Good catch!
I thought about the documentation but not the examples therein.
Updated patch attach
that a
> pg_stat_reset() causes an immediate autovacuum for all tables, so maybe
> it's not quite that simple.
Not just pg_stat_reset() but also on promotion.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
alled just once per row rather than each time like the first query.
Is this as designed? It's certainly unexpected, and my initial reaction
is undesirable.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
plain_format.
Of course if you default BUFFERS to on(*) and don't do ANALYZE, that
should not result in an error.
(*) Defaulting BUFFERS to on is something I want regardless of anything
else we do.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.
that the user might have been trying to use a window function.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c
index c745fcdd2
a patch to create a function for it, based off 5953c99697.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96d45419e5..304fa638fe 100644
application of AT TIME ZONE 'Australia/Sydney',
> but that's both inefficient
Hmm, converting it back is exactly what my function does...
> and mighty confusing.
This is my justification for needing the patch.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 29/10/2018 16:26, Andreas Karlsson wrote:
> On 10/29/2018 04:18 PM, Vik Fearing wrote:
>> A use case that I see quite a lot of is needing to do reports and other
>> calculations on data per day/hour/etc but in the user's time zone. The
>> way to do that is fairly tri
On 29/10/2018 17:12, Steve Crawford wrote:
> On Mon, Oct 29, 2018 at 8:44 AM Vik Fearing <mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> On 29/10/2018 16:26, Andreas Karlsson wrote:
> > On 10/29/2018 04:18 PM, Vik Fearing wrote:
> >> A use case tha
ached patch add this possibility to least, greatest functions.
Is there any particular reason you didn't just make least and greatest
actual functions?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 14/11/2018 21:42, Tom Lane wrote:
> I wrote:
>> Here's a v2 that transposes the code to C so that we can get that
>> optimization.
>
> Pushed after a bit more testing and documentation-wordsmithing.
Thank you, Tom!
--
Vik Fearing
questionably,
> one decision about whether to do crash recovery before entering archive
> recovery, but nothing else.)
Bump.
I was the originator of this report. I work with Postgres every single
day and I was spooked by these warnings. People with much less
involvement would probably be terrified.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
dicate it applies to
>>> statement logging. I'd say log_statement_sample_rate is better.
>>
>> I agree, sounds reasonable.
>>
>
> Thanks for your comments. Here is the updated patch. I fixed a warning for
> missing parentheses in this expression:
> if ((excee
sideration
into Andrew Gierth's approach. I would rather see something like that.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 25/11/2018 12:49, Surafel Temesgen wrote:
>
>
> On Sun, Nov 25, 2018 at 1:24 PM Vik Fearing <mailto:vik.fear...@2ndquadrant.com>> wrote:
>
>
> Also, this query returns 210 rows instead of the expected 208:
>
> select *
> from gene
:
>
> select pg_stat_statements_reset(NULL,NULL,NULL);
> -- No change, just return. Because the function is strict.
>
> select pg_stat_statements_reset(0,0,0);
> -- Resets all the statements
>
> select pg_stat_statements_reset(0,10,0);
> -- Resets all the statements exe
ction not
parallel safe?
Sure it could be mislabeled as immutable but it could just as easily be
mislabeled as parallel safe. And we already treat fake immutable
functions as user errors, for example in indexes.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQu
On 27/11/2018 00:39, Andres Freund wrote:
> Hi,
>
> On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
>> On 26/11/2018 22:23, Gajus Kuizinas wrote:
>>> I was wondering what is the reason IMMUTABLE functions are not by
>>> default PARALLEL SAFE and if the defa
Does that mean we also shouldn't assume that functions marked as
immutable are index safe?
User error is user error.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
signature.asc
Description: OpenPGP digital signature
On 27/11/2018 01:10, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:05, Stephen Frost wrote:
>>> That said, I do *not* think we should make any assumptions here- users
>>> incorrectly mark things all th
On 27/11/2018 01:14, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:10, Stephen Frost wrote:
>>> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>>>> On 27/11/2018 01:05, Stephen Frost wrote:
immutable
function is not parallel safe.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
signature.asc
Description: OpenPGP digital signature
On 27/11/2018 01:40, Tom Lane wrote:
> Vik Fearing writes:
>> On 27/11/2018 01:13, Stephen Frost wrote:
>>> Parallel safe functions should be marked as such. Immutable functions
>>> should be marked as such. We should not assume that one implies the
>>> oth
-
column1 column2
- -
hello\ 42
world
single line 5
another
-------
(3 rows)\
This handles both column alignment and the multiline issue Daniel raised.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
7;d like to ask you
> So now, I think we need to ask that fundamental question :
>
> ***Is it worth it ?***
And my answer to that is:
No. Markdown isn't standardized enough to support and please everyone.
--
Vik Fearing +33 6 46 75 15 36
htt
params (per queryid).
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 03/04/2018 08:06 PM, Tom Lane wrote:
> Edmund Horner writes:
>> On 26 January 2018 at 13:44, Vik Fearing wrote:
>>> On 01/26/2018 01:28 AM, Edmund Horner wrote:
>>>> The patch mentioned attempts to put savepoints around the tab
>>>> completion query
On 03/05/2018 11:33 AM, Edmund Horner wrote:
> On 5 March 2018 at 21:46, Vik Fearing wrote:
>> Tab completion on functions in SELECT (a subset of this thread's patch)
>> is quite important to me personally. I will work on this in the coming
>> days.
>
> It's
On 03/05/2018 11:21 AM, Edmund Horner wrote:
> I am still just slightly unclear on where we are in relation to the
> SAVEPOINT patch -- is that redundant now?
My vote is to reject that patch.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadr
the
same, but I would have to research that.
--
Vik Fearing
ow to handle dump/restore. The
standard does not bother thinking about that.
--
Vik Fearing
means resorting to the hated "implementation-defined".
--
Vik Fearing
just Y/X (but why
in that order?), so I didn't think it was necessary. If others feel more
strongly, I can add those too.
No comment on adding names for everything, but a big +1 for the ones
included here.
--
Vik Fearing
.
Internally, all the numeric literal parsing of jsonpath goes through
numeric_in, which already supports all this, so this patch is just a bit
of lexer work and some tests.
Is T840 really NO after this patch?
--
Vik Fearing
inent, we can just add that anyway. I think being
able to say
COLLATE UNICODE
instead of
COLLATE "und-x-icu"
or whatever it is, is pretty useful.
So, attached is a small patch to add this.
I don't feel competent to review the patch (simple as it is), but +1 on
th
t value without considering the constraints of
a domain is a bug that needs to be fixed in the standard.
--
Vik Fearing
On 3/22/24 00:17, Tom Lane wrote:
Vik Fearing writes:
On 3/21/24 15:30, Tom Lane wrote:
The SQL spec's answer to that conundrum appears to be "NULL is
a valid value of every domain, and if you don't like it, tough".
I don't see how you can infer this from the sta
On 3/22/24 01:46, Tom Lane wrote:
Vik Fearing writes:
Anyway, I will bring this up with the committee and report back. My
proposed solution will be for CAST to check domain constraints even if
the input is NULL.
Please do not claim that that is the position of the Postgres project
bikeshedding, but this is the approach I am aiming for.
Thoughts?
--
Vik Fearing
On 12/13/22 13:55, Magnus Hagander wrote:
On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing wrote:
The standard only defines an ORDER BY clause inside of an aggregate for
ARRAY_AGG(). As an extension to the standard, we allow it for all
aggregates, which is very convenient for non-standard things
On 12/13/22 14:25, Isaac Morland wrote:
On Tue, 13 Dec 2022 at 07:50, Vik Fearing wrote:
I am proposing something like pg_aggregate.aggordering which would be an
enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
all aggregates would have 'a' but I am thinking
rdering is
underspecified.
That is a good point
I also wonder whether we'd accept any ORDER BY whatsoever, or try
to require one that produces a sufficiently-unique input ordering.
I would accept anything. agg(x order by y) is a common thing.
--
Vik Fearing
would use our own language?
--
Vik Fearing
On 12/18/22 15:24, Tom Lane wrote:
Vik Fearing writes:
Are there any objections to me writing a patch to add SQL Standard
regular expression functions even though they call for XQuery and we
would use our own language?
Yes. If we provide spec-defined syntax it should have spec-defined
yway.
I don't know what my opinion is on that.
--
Vik Fearing
haps a bit off-topic, but what is the point of the file identifiers?
--
Vik Fearing
new types
for every type like we do for arrays on the off-chance you would want to
put it in a PERIOD for example.
For those who know the code much better than I do, what would be a
plausible way forward to support these containers?
--
Vik Fearing
, what does the specification tells about seeds, normal and random
functions?
Nothing at all.
--
Vik Fearing
On 12/23/22 00:47, David Rowley wrote:
On Wed, 26 Oct 2022 at 14:38, David Rowley wrote:
I've now pushed the final result. Thank you to everyone who provided
input on this.
This is a very good improvement. Thank you for working on it.
--
Vik Fearing
101 - 200 of 475 matches
Mail list logo
