another couple of similar comments that also needed updating,
so I've pushed a fix for them too.
Regards,
Dean
On Fri, 17 May 2024 at 09:22, Dean Rasheed wrote:
>
> On Wed, 15 May 2024 at 02:14, Erik Wienhold wrote:
> >
> > plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
> >
> > Fixed in the attached patch.
> >
>
> Nice catch! The patch looks go
On Mon, 13 Mar 2023 at 13:36, Dean Rasheed wrote:
>
> And another rebase.
>
I ran out of cycles to pursue the MERGE patches in v16, but hopefully
I can make more progress in v17.
Looking at this one with fresh eyes, it looks mostly in good shape. To
recap, this adds support for the
On Tue, 21 Mar 2023 at 12:26, Alvaro Herrera wrote:
>
> On 2023-Mar-21, Dean Rasheed wrote:
>
> > Looking at it with fresh eyes though, I realise that I could have just
> > written
> >
> > action->qual = make_and_qual((Node *) ntest, action->qual)
alance, delta)
> +ON tid = v.sid
> +WHEN MATCHED AND tid > 2 THEN
>
> Again, for consistency, the comparison operator should be >=. There
> are a few more occurrences of this comparison in the rest of the file,
> that need the same treatment.
>
I changed the n
On Wed, 21 Aug 2024 at 08:00, Peter Eisentraut wrote:
>
> On 08.08.24 20:22, Dean Rasheed wrote:
> > Looking at the rewriter changes, it occurred to me that it could
> > perhaps be done more simply using ReplaceVarsFromTargetList() for each
> > RTE with virtual generate
they seem to confirm my previous
observation that exact mode is faster than approximate mode for
var2ndigits <= 12 or so, so I've added code to do that.
I also expanded on the comments for the quotient-correction code a bit.
Regards,
Dean
From 0b5ae26beb3b7cd0c68c566f01c527e59a264386 Mon Se
On Sat, 24 Aug 2024 at 19:17, Tom Lane wrote:
>
> About a dozen buildfarm members are complaining
>
Ah, OK. I've pushed a fix.
Regards,
Dean
datable_views.sql?
> Do we need to add some tests?
>
I don't think so, because varreturningtype doesn't affect any
permissions checks.
> Other than that, I didn't find any issue.
Thanks for reviewing.
If there are no other issues, I think this is probably ready for commit.
Regards,
Dean
On Tue, 3 Sept 2024 at 21:31, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Ah, OK. I've pushed a fix.
>
> There is an open CF entry pointing at this thread [1].
> Shouldn't it be marked committed now?
>
Oops, yes I missed that CF entry. I've closed it now
On Wed, 4 Sept 2024 at 09:40, Peter Eisentraut wrote:
>
> On 21.08.24 12:51, Dean Rasheed wrote:
> >>
> > Well what I was thinking was that (in fireRIRrules()'s final loop over
> > relations in the rtable), if the relation had any virtual generated
> > column
x27;m reading that lgamma() in the C library is not necessarily
> thread-safe. Is that a possible problem?
It's not quite clear what to do about that. Some platforms may define
the lgamma_r() function, but not all. Do we have a standard pattern
for dealing with functions for which there is
hould be finite, but is too large to be
represented in a double.
In particular, this means that zero and negative integer inputs are
not genuine overflows, but should return NaN or +/-Inf, as described
in the POSIX spec.
Doing that, and assuming that tgamma() and lgamma() behave according
to spec,
On Fri, 6 Sept 2024 at 10:42, Dean Rasheed wrote:
>
> ... assuming that tgamma() and lgamma() behave according to spec ...
Nope, that was too much to hope for. Let's see if this fares any better.
Regards,
Dean
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file
many rows were filtered out:
- Use pg_stat_get_tuples_returned()
- Use pg_class.reltuples
- Use the row estimates from a plain EXPLAIN
and probably more.
Given that this isn't really a security bug, I think EXPLAIN should
probably be left as-is. Otherwise, you'd have to go round closing all
those other "holes" too.
Regards,
Dean
translate(substring(&primary;, 1, 1),
>
This looks like you're missing a required package. Try installing
docbook-xsl or docbook-xsl-stylesheets or something similar (the
package name varies depending on your distro).
Regards,
Dean
code wants to ignore RangeTblRef
nodes, but it could delegate to ChangeVarNodes() for various other
node types to avoid code duplication. At the top level, the stuff that
ChangeVarNodes() does to fields of the Query struct would be different
for SJE, I think.
Regards,
Dean
e extensible, if we wanted it to
return more information in the future.
Instead of adding relation_has_unique_index_ext(), maybe it would be
OK to just change the signature of relation_has_unique_index_for(). It
looks like it's only called from one other place outside
analyzejoins.c. Perhaps the same is true for innerrel_is_unique_ext().
Should match_unique_clauses() be comparing mergeopfamilies or opnos to
ensure that the clauses are using the same equality operator?
Regards,
Dean
On Fri, 12 Jul 2024 at 13:34, Dean Rasheed wrote:
>
> Then I tried compiling with -m32, and unfortunately this made the
> patch slower than HEAD for small inputs:
>
> -- var1ndigits1=5, var2ndigits2=5 [-m32, SIMD disabled]
> call rate=5.052332e+06 -- HEAD
> call rate=3.88
ch is much faster. With the
patch, they both generate the same SSE2 code, so the results are
pretty consistent.
Regards,
Dean
ou found [1], I think it's entirely
possible that there are people who care about 32-bit systems, which
means that we might well get complaints, if we make it slower for
them. Unfortunately, I don't have any way to test that (I doubt that
running a 32-bit executable on my x86-64 system is a realistic test).
Regards,
Dean
[1] https://postgr.es/m/0a71b43129fb447988f152941e1db...@nidsa.net
f 32-bit-specific code
that significantly complicates this function, making it harder to
maintain. Without that code, the patch becomes much simpler, which
seems like a decent justification for any performance tradeoffs on
32-bit machines that are unlikely to affect many people anyway.
Regards,
Dea
so it wouldn't need to worry about
CTEs and sublink subqueries. That would also make the
hasGeneratedVirtual flags unnecessary, since we'd already only be
doing the extra work for tables with virtual generated columns. That
would eliminate possible bugs caused by failing to set those flags.
Regards,
Dean
examples where the patch differs from
HEAD, but hopefully only by being more accurate, not less.
Regards,
Dean
From 6c1820257997facfe8e74fac8b574c8f683bbebc Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Thu, 18 Jul 2024 17:38:59 +0100
Subject: [PATCH v5 1/2] Extend mul_var_short() to 5 and
-
282595
(1 row)
select * from diffs2 except select * from diffs1;
n | z | m | w | x | y | expected | numeric_mul_rscale
---+---+---+---+---+---+--+
(0 rows)
which is exactly what I was hoping to see (no cases where the patch
made it less accurate).
Regards,
Dean
test-rscale.sql
Description: application/sql
series terms when deciding on the local rscale). That
wasn't affected significantly by the patch, and it's not surprising
that you saw nothing with brute-force testing.
In any case, I'm pretty content with those results.
Regards,
Dean
functions in some
circumstances.
When casting a numeric to an integer, the result is rounded to the
nearest integer, and NaN/Inf generate errors, so we should probably do
the same here.
Regards,
Dean
nitialised.
> I propose back-patching 0001/0002 as far as v12, since the failure
> to match the old outputs seems like a pretty clear bug/regression.
> However, I'd be content to apply 0003 only to HEAD. That misbehavior
> is very ancient, and the lack of complaints suggests that few people
> really care about this fine point.
Makes sense.
Regards,
Dean
;. However, I
don't think that's particularly useful, and it fails the first test
that the result exactly divides both inputs because mod('Inf', 'Inf')
is undefined ('NaN').
Similar arguments apply to lcm(), so I'd say that both gcd() and lcm()
should return 'NaN' if either input is 'Inf' or 'NaN'.
Regards,
Dean
tive inputs, or even complex
inputs by defining it in terms of the gamma function. However, even
then, it is undefined for negative integer inputs.
Regards,
Dean
[1] https://en.wikipedia.org/wiki/Factorial
[2] https://en.wikipedia.org/wiki/Gamma_function
On Tue, 16 Jun 2020 at 09:55, Bruce Momjian wrote:
>
> On Tue, Jun 16, 2020 at 08:31:21AM +0100, Dean Rasheed wrote:
> >
> > Most common implementations do regard factorial as undefined for
> > anything other than positive integers, as well as following the
> > co
ferable to erroring-out
in some contexts.
[1] https://www.postgresql.org/message-id/606717.1591924582%40sss.pgh.pa.us
Regards,
Dean
On Tue, 16 Jun 2020 at 12:18, Peter Eisentraut
wrote:
>
> On 2020-06-16 11:49, Dean Rasheed wrote:
> > With [1], we could return 'Infinity', which would be more correct from
> > a mathematical point of view, and might be preferable to erroring-out
> > in some
hile looking at edge cases -- float and numeric handle
NaN/0 differently:
SELECT 'nan'::float8 / 0::float8;
ERROR: division by zero
SELECT 'nan'::numeric / 0::numeric;
?column?
--
NaN
I'm not sure if this is worth worrying about, or which behaviour is
preferable though.
Regards,
Dean
ouldn't "infinitely precede" itself,
> I think. (Maybe if you got solipsistic enough you could argue
> that that is valid, but it seems pretty bogus.)
>
Hmm, that code looks a bit fishy to me, but I really need to think about it
some more. I'll take another look tomorrow, and maybe it'll become clearer.
Regards,
Dean
On Thu, 16 Jul 2020 at 20:29, Tom Lane wrote:
>
> Dean Rasheed questioned this longstanding behavior:
>
> regression=# SELECT 'nan'::float8 / '0'::float8;
> ERROR: division by zero
>
> After a bit of research I think he's right: per IEEE 754 this sh
On Fri, 17 Jul 2020 at 01:59, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
> >> Actually, after staring at those results awhile longer, I decided
> >> they were wrong. The results shown here seem actually sane --
that is
much more readable than having to read and interpret a piece of free
text.
Similarly, for other functions like gcd(), lcm() and mod(). I think it
would be better to get rid of numeric_type, and just list all the
variants of each function.
Regards,
Dean
e. David's review comments were
excellent. I'll try to review it as well when you post your next
update.
I have some more fundamental doubts about the histogram patch, to do
with the way it integrates with selectivity estimation, and some vague
half-formed ideas about how that could be improved, but nothing clear
enough that I can express right now.
So yes, let's focus on the MCV patch for now.
Regards,
Dean
bl2 while values for
the identity columns in tbl2 will be generated by
the sequences associated with tbl2.
which currently only works for a GENERATED BY DEFAULT identity column,
but should work equally well for a GENERATED ALWAYS identity column.
So I propose the attached patch.
Regard
n't really accomplish that.
> OVERRIDING USER VALUE is only useful in the specific situations that the
> documentation discussed. Can we detect those?
>
Hmm, I'm not sure that we reliably guess what the user intended. What
exactly did you have in mind?
Regards,
Dean
On Tue, 12 Feb 2019 at 10:33, Dean Rasheed wrote:
> Here's an updated patch ...
So I pushed that. However, ...
Playing around with it some more, I realised that whilst this appeared
to fix the reported problem, it exposes another issue which is down to
the interaction
continue; /* Uniqueness definitely not violated */
}
If you trace it back, you'll see that for a statement-level trigger,
recheckIndexes will always be empty.
Regards,
Dean
On Tue, 25 Dec 2018 at 08:04, Dean Rasheed wrote:
> Take a look at this code in AfterTriggerSaveEvent():
>
Note that the intention behind that code is that in the (fairly
common) case where an insert or update operation is known to not lead
to any potential PK/UNIQUE index violation
tter cap on the non-MCV selectivities. So if, after keeping all
items satisfying rule (b), there are free slots available, perhaps
they should be used for the most common remaining values satisfying
rule (a).
Regards,
Dean
s.
>
Looks good to me.
Regards,
Dean
harsh to flat-out reject these
messages. My prior understanding was that cross-posting, while
generally discouraged, does still sometimes have value.
[1]
https://www.postgresql.org/message-id/flat/CAEZATCVqksrnXybSaogWOzmVjE3O-NqMSpoHDuDw9_7mhNpeLQ%40mail.gmail.com#2c25e9a783d4685912dcef8b3f3edd63
Regards,
Dean
On Wed, 9 Jan 2019 at 15:40, Tomas Vondra wrote:
> On 1/8/19 3:18 PM, Dean Rasheed wrote:
> > So actually, the estimate for a group of values will be either the MCV
> > item's frequency (if the MCV item is kept), or (roughly) the MCV
> > item's base_frequency (if
mitted ahead of these ones, and I'd
also argue for back-patching it.
That's it for now. I'll try to keep reviewing if time permits.
Regards,
Dean
On Fri, 11 Jan 2019, 21:18 Tomas Vondra
> On 1/10/19 4:20 PM, Dean Rasheed wrote:
> > ...
> >
> > So perhaps what we should do for multivariate stats is simply use the
> > relative standard error approach (i.e., reuse the patch in [2] with a
> > 20% RSE cutoff).
On Sun, 13 Jan 2019 at 00:04, Tomas Vondra wrote:
> On 1/12/19 8:49 AM, Dean Rasheed wrote:
> > A possible refinement would be to say that if there are more than
> > stats_target items more common than this mincount threshold, rather than
> > excluding the least common o
(Removing Adrien from the CC list, because messages to that address
keep bouncing)
On Sun, 13 Jan 2019 at 00:31, Tomas Vondra wrote:
>
> On 1/10/19 6:09 PM, Dean Rasheed wrote:
> >
> > In the previous discussion around UpdateStatisticsForTypeChange(), the
> > consensu
doubles, independent of
ndims.
> ndims should also have parenthesis around it in case someone does
> ITEM_SIZE(x + y), likewise for the other ITEM_* macros.
>
+1 on that point.
Regards,
Dean
> * like for the single-dimensional MCV list.
>
Right. Also, analyze_mcv_list() is no longer being used anywhere
outside of analyze.c, so it can go back to being static.
Regards,
Dean
question about security
> implications, we should err in the conservative direction of leaving
> it untrusted.
>
+1
I wonder if the same could be said about pgrowlocks.
Regards,
Dean
ith div_var() for various
inputs.
It's possible that there are further gains to be had in the sqrt()
algorithm on platforms that support 128-bit integers, but I haven't
had a chance to investigate that yet.
Regards,
Dean
[1] https://hal.inria.fr/inria-00072854/document
numeric-sqrt-ln.patch
Description: Binary data
On Fri, 28 Feb 2020 at 08:15, Dean Rasheed wrote:
>
> It's possible that there are further gains to be had in the sqrt()
> algorithm on platforms that support 128-bit integers, but I haven't
> had a chance to investigate that yet.
>
Rebased patch attached, now using 128
ecially in the numeric iterations, where it
saves a sub_var() by const_one as well as not using the temporary
variable.
Regards,
Dean
d by a large number of regression tests in both
numeric.sql and numeric_big.sql, since nearly anything that calls
ln(), log() or pow() ends up going through sqrt_var(). Also, the
changes are local to functions in numeric.c, which makes them easy to
revert if something proves to be wrong.
Regards,
Dean
OR b = 0 OR c = 0 OR d = 0;
Similarly, if no extended stats can be applied it needs to return 0
not 1, for example this query on the test data:
SELECT * FROM mcv_lists WHERE a = 1 OR a = 2 OR d IS NOT NULL;
It might also be worth adding a couple more regression test cases like these.
Regards,
Dean
)*P(a)*P(b)
I.e., for those rows believed to be functionally dependent, we use the
minimum probability, and for the rows believed to be independent, we
use the product.
I think that would solve the problem with the example you gave at the
end of [2], but I'm not sure if it helps with the ge
On Thu, 6 Jun 2019 at 21:33, Tomas Vondra wrote:
>
> Hi,
>
> Attached are three patches tweaking the stats - two were already posted
> in this thread, the third one is just updating docs.
>
> 1) 0001 - split pg_statistic_ext into definition + data
>
> This is pretty
Discard all values with count < mincount.
2). Order by freq*Abs(freq-base_freq) (or possibly just
Abs(freq-base_freq)) and keep the top n, where n is the stats target.
3). Perhaps re-sort by count, so the final list is in frequency order
again? Not sure if that's a desirable property to keep.
Regards,
Dean
gt;
Yes it does look a bit weird, but that's the natural generalisation of
what we have for per-column statistics, so it's probably preferable to
do that rather than invent some other syntax that wouldn't be so
consistent.
Regards,
Dean
On Thu, 20 Jun 2019 at 23:12, Tomas Vondra wrote:
>
> On Thu, Jun 20, 2019 at 08:08:44AM +0100, Dean Rasheed wrote:
> >On Tue, 18 Jun 2019 at 22:34, Tomas Vondra
> >wrote:
> >>
> >> So I'm thinking we should allow tweaking the statistics for ext
On Thu, 20 Jun 2019 at 23:35, Tomas Vondra wrote:
>
> On Thu, Jun 20, 2019 at 06:55:41AM +0100, Dean Rasheed wrote:
>
> >I'm not sure it's easy to justify ordering by Abs(freq-base_freq)/freq
> >though, because that would seem likely to put too much weight on
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
>
> On Fri, May 10, 2019 at 10:19:44AM +0100, Dean Rasheed wrote:
> >While working on 1aebfbea83c, I noticed that the new multivariate MCV
> >stats feature suffers from the same problem, and also the original
> >pro
e column is 1/3e6, so for 2 columns it'd be ~1/9e12 (which I think is
> something the float8 can represent).
>
Yeah, it should be impossible for the base frequency to underflow to
0. However, it looks like the problem is with mcv_list_items()'s use
of %f to convert to text, which is pretty ugly.
Regards,
Dean
On Mon, 24 Jun 2019 at 00:42, Tomas Vondra wrote:
>
> On Sun, Jun 23, 2019 at 10:23:19PM +0200, Tomas Vondra wrote:
> >On Sun, Jun 23, 2019 at 08:48:26PM +0100, Dean Rasheed wrote:
> >>On Sat, 22 Jun 2019 at 15:10, Tomas Vondra
> >>wrote:
> >>&g
#x27;t want any additional catversion bumps,
> it's possible to pass the arrays through output functions - that would
> allow us keeping the text output (but correct, unlike what we have now).
>
I think this is a clear bug fix, so I'd vote for fixing it properly
now, with a catversion bump.
Regards,
Dean
-- the new code
needs to be calling statistic_proc_security_check() to determine
whether it's OK to be using these statistics -- c.f. commit
e2d4ef8de8.
Similarly, I think that access to pg_statistic_ext should be
restricted in the same way that access to pg_statistic is, with a SB
view o
.
Perhaps this is not so very different from what you're currently
doing, except that with this approach we might also end up with
mcv_sel = 0 and hist_sel = 0, but still have an improved simple_sel
estimate that had accounted for some the multivariate stats available
along the way.
Regards,
Dean
. But it would
also need to track inequalities, with min/max values or fractions of
the non-MCV total, or some such thing.
Regards,
Dean
a | b | frequency
>---
> 1 | 1 | 0.5
> 2 | 2 | 0.5
>
> And let's estimate sel(a=1 & b=2).
OK.In this case, there are no MCV matches, so there is no lower bound (it's 0).
What we could do though is also impose an upper bound, based on the
sum of non-matching MCV frequencies. In this case, the upper bound is
also 0, so we could actually say the resulting selectivity is 0.
Regards,
Dean
On 16 July 2018 at 21:55, Tomas Vondra wrote:
>
>
> On 07/16/2018 02:54 PM, Dean Rasheed wrote:
>> On 16 July 2018 at 13:23, Tomas Vondra wrote:
>>>>> The top-level clauses allow us to make such deductions, with deeper
>>>>> clauses it's muc
RAND_poll();
which seems preferable. Attached is a patch to do this in pg_strong_random().
Thoughts?
Regards,
Dean
[1] https://www.openssl.org/docs/man1.1.1/man3/RAND_status.html
[2] https://github.com/nodejs/node/blob/master/src/node_crypto.cc
[3] https://github.com/openssl/openssl/iss
On 17 July 2018 at 14:04, Michael Paquier wrote:
> On Tue, Jul 17, 2018 at 01:33:11PM +0100, Dean Rasheed wrote:
>> Looking for precedents elsewhere, I found [2] which does exactly that,
>> although I'm slightly dubious about the need for the for-loop there. I
>> also
wisdom to check for a failure on RAND_poll().
OK, I guess that it is possible that an older version of OpenSSL
requires RAND_poll() to be called multiple times. Here's an updated
patch doing that (with up to 8 retries, based on the old OpenSSL
code).
Regards,
Dean
diff --git a/src/por
y further comments, I'll push and back-patch this to v10
later this week.
Regards,
Dean
at amounts to sorting by
cost/(1-sel) rather than just cost, except for clauses with sel==1,
which it makes sense to move to the end, and just sort by cost.
Regards,
Dean
ed patch for that.
>
In the case 1 ^ NaN = 1, what should the result scale be?
For other inputs, the result scale is at least as large as the scale
of the first input, so I would suggest that the same ought to be the
case here.
Otherwise, this looks fine, and I agree that it makes thinks neater /
more consistent.
Regards,
Dean
On 16 May 2018 at 14:44, Tom Lane wrote:
> Dean Rasheed writes:
>> In the case 1 ^ NaN = 1, what should the result scale be?
>
> The result is exact, so I don't see a reason to be worried about its
> scale. Messing with the scale would also require expending even
> mo
e <> 'pg_catalog'
AND n.nspname <> 'information_schema'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 1,2
) as t
;
That would allow things like
\d+ (order by size)
which would sort by the numeric size, while displaying the pretty size
in the output.
This would also allow more complex orderings that would be hard to
achieve any other way, such as
\d+ (order by type, schema, size desc)
\dt (order by pg_total_relation_size(name::regclass))
(note the size reported by \d+ is not the total relation size, because
it excludes indexes)
Also, it would allow user-defined WHERE clauses to filter the results
shown, for example:
\d+ (where size > pg_size_bytes('1GB'))
\dv (where pg_relation_is_updatable(name::regclass, true) != 0)
and many more things are possible, without needing to learn any new
syntax, and without needing to keep adding more and more options to
the psql syntax.
Regards,
Dean
rong to
AND together the ALL policies with the SELECT policies and the UPDATE
policies.
With the above changes, there are more command types than policy
types, so it also makes sense to swap the orientation of the table.
Here's an updated patch, with the table done that way. Co
oid
the possible renumbering of the resjunk entries.
Regards,
Dean
On 27 November 2017 at 16:35, Tom Lane wrote:
> I wrote:
>> Dean Rasheed writes:
>>> A separate point -- it might be marginally more efficient to have the
>>> work of rewriteTargetListUD() done after expand_targetlist() to avoid
>>> the possible renumbering
regate
-> Parallel Seq Scan on foo
Filter: ((a % 10) = zero)
(6 rows)
select count(*) from foo where a%10 = zero;
count
---
38037-- Different random result each time, should be 100,000
(1 row)
Thoughts?
Regards,
Dean
On 3 September 2018 at 00:17, Tomas Vondra wrote:
> Hi,
>
> Attached is an updated version of the patch series, adopting a couple of
> improvements - both for MCV lists and histograms.
>
>
> MCV
> ---
>
> For the MCV list part, I've adopted the approach propose
Syy, and likewise when they are combined, so there is no way that
they can ever become negative now. Another neat consequence of this
algorithm.
I'll post an updated patch in a while.
Regards,
Dean
On Thu, 27 Sep 2018 at 14:22, Dean Rasheed wrote:
> I'll post an updated patch in a while.
>
I finally got round to looking at this again. Here is an update, based
on the review comments.
The next question is whether or not to back-patch this. Although this
was reported as a bug, my
https://www.postgresql.org/docs/current/tablefunc.html
They really should have their own subsection, along the same lines as
"F.41.1.1. Normal_rand", explaining what the functions do, what their
arguments mean, and giving a couple of usage examples.
Regards,
Dean
On Sun, 25 Aug 2024 at 10:33, Joel Jacobson wrote:
>
> Nice. LGTM.
> I've successfully tested the new patch again on both Intel and AMD.
>
> I've marked it as Ready for Committer.
>
[Finally getting back to this]
Thanks for the review and testing.
Committed.
Regards,
Dean
ersed. For example,
imagine you wanted to use raw_expression_tree_walker() to print out
the whole structure of a raw parse tree. You'd want your printing
callback to be called for every node, including the ReturningOption
nodes.
Regards,
Dean
ments so
far though, so I think we should make a decision, and then standardise
on whatever people decide.
Regards,
Dean
{{1,2},{3,4},{10,20}}
Regards,
Dean
-bounds, like array_fill(). I.e., something like:
random_array(min int, max int, dims int[] [, lbounds int[]]) -> int[]
Returns an array filled with random values in the range min <= x <= max,
having dimensions of the lengths specified by dims. The optional lbounds
argument supplies lower-bound values for each dimension (which default
to all 1).
Regards,
Dean
tes random values, more
similar to the random(min, max) functions. Also I think it's more
useful if it shares the same PRNG, controlled by setseed(), and it
makes sense to group all such functions together.
Regards,
Dean
;t
look like those patches were committed, and there are still many such
warnings, if you try compiling postgres with those flags.
[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKGJ7EQm9extQAgrFZNNUKqRT8Vv5t1tKqA-5nEcYn0%2BwNA%40mail.gmail.com
I don't know if anyone has any plans to pick up that work again, but
in any case, it seems wise to not add more.
Regards,
Dean
ter fixing that, I think it's sufficient to just list one
usage example.
Regards,
Dean
From 2a14be071dd2e721e768fdbaa57b096d509773aa Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Wed, 30 Oct 2024 08:41:41 +
Subject: [PATCH v3] tablefunc: Add rand_array() functions.
These functions
RelationDesc,
PRS2_NEW_VARNO);
Regards,
Dean
501 - 600 of 690 matches
Mail list logo
