On Tue, 5 Jul 2022 at 19:00, Tom Lane wrote:
>
> Dean Rasheed writes:
> > This was discussed previously in [1], and there seemed to be general
> > consensus in favour of it, but no new patch emerged.
>
> As I said in that thread, I'm not super enthused about thi
While doing more testing of [1], I realised that it has a bug, which
reveals a pre-existing problem in transformLockingClause():
CREATE TABLE t1(a int);
CREATE TABLE t2(a int);
CREATE TABLE t3(a int);
SELECT 1
FROM t1 JOIN t2 ON t1.a = t2.a,
t3 AS unnamed_join
FOR UPDATE OF unnamed_join;
ER
On Wed, 6 Jul 2022 at 15:09, Dean Rasheed wrote:
>
> I'll post an update in a little while, but first, I found a bug, which
> revealed a pre-existing bug in transformLockingClause(). I'll start a
> new thread for that, since it'd be good to get that resolved
&g
On Mon, 13 Dec 2021 at 02:21, Tomas Vondra
wrote:
>
> Hi,
>
> I finally got around to this patch again, focusing mostly on the first
> part that simply returns either 1.0 or 0.0 for Var op Var conditions
> (i.e. the part not really using extended statistics).
>
Just starting to look at this again
On Sat, 9 Jul 2022 at 12:24, Zhihong Yu wrote:
>
> It seems the code would be more readable if you keep the assignment in else
> block below:
>
> + else if (rte->rtekind == RTE_SUBQUERY ||
> +rte->rtekind == RTE_VALUES)
> cont
On Tue, 19 Jul 2022 at 21:21, Martin Kalcher
wrote:
>
> Here is a patch with dimension aware array_shuffle() and array_sample().
>
+1 for this feature, and this way of handling multi-dimensional arrays.
> If you think array_flatten() is desirable, i can take a look at it.
That's not something I
On Thu, 21 Jul 2022 at 12:15, Martin Kalcher
wrote:
>
> I agree that we should use pg_prng_uint64_range(). However, in order to
> achieve interoperability with setseed() we would have to use
> drandom_seed (rather than pg_global_prng_state) as rng state, which is
> declared statically in float.c a
his using a
new opt_stats_name production in the grammar, as in the attached.
I also noticed a comment in CreateStatistics() that needed updating.
Barring any further comments, I'll push this shortly.
Regards,
Dean
From 8963355b2d8451be8f71a3bd2890e99e31f7d3ff Mon Sep 17 00:00:00 2001
From
On Thu, 21 Jul 2022 at 18:42, Alvaro Herrera wrote:
>
> Thanks. I was looking at the recently modified REINDEX syntax and
> noticed there another spot for taking an optional name. I ended up
> reusing OptSchemaName for that, as in the attached patch. I think
> adding production-specific additio
On Thu, 21 Jul 2022 at 16:43, Martin Kalcher
wrote:
>
> Am 21.07.22 um 14:25 schrieb Dean Rasheed:
> >
> > I'm inclined to say that we want a new pg_global_prng_user_state that
> > is updated by setseed(), and used by random(), array_shuffle(),
> > array_sample(
On Fri, 22 Jul 2022 at 10:31, Martin Kalcher
wrote:
>
> i came to the same conclusions and went with Option 1 (see patch).
> Mainly because most code in utils/adt is organized by type and this way
> it is clear, that this is a thin wrapper around pg_prng.
>
> What do you think?
Looks fairly neat,
On Thu, 21 Jul 2022 at 12:42, Tomas Vondra
wrote:
>
> > This needs to account for nullfrac, since x = x is only true if x is not
> > null.
>
> Right, I forgot to account for nullfrac.
>
Ditto variable <= variable
> > I don't like how matching_restriction_variables() is adding a
> > non-trivial
On Thu, 2 Sept 2021 at 00:39, Jaime Casanova
wrote:
>
> Hi Dean,
>
> It seems you already committed this. But it's still as "Ready for
> committer" in the commitfest app.
>
> Are we waiting for something else or we can mark it as committed?
>
It's mostly done, but there is one more corner case wh
On Thu, Sep 02, 2021 at 07:27:09AM +0100, Dean Rasheed wrote:
>
> It's mostly done, but there is one more corner case where it loses
> precision. I'll post an update shortly.
>
I spent some more time looking at this, testing a variety of edge
cases, and the only case I co
On Mon, 13 Sept 2021 at 17:51, Alvaro Herrera wrote:
>
> I came here just to opine that there should be a comment about there not
> being a clamp to the maximum scale. For example, log_var says "Set the
> scales .. so that they each have more digits ..." which seems clear
> enough; I think the ne
On Sat, 18 Sep 2021, 18:06 Tom Lane, wrote:
>
> I'm inclined to back-patch
>
+1
Regards,
Dean
>
On Thu, 30 Sept 2021 at 18:25, Jaime Casanova
wrote:
>
> Are you planning to commit this soon?
>
Yes, I'll take a look at it next week.
I think it's worth backpatching, despite the fact that it's a pretty
obscure corner case that probably isn't affecting anyone -- similar
fixes in this area have
On Mon, 12 Jul 2021 at 17:39, vignesh C wrote:
>
> Thanks for your comments, I have made the changes for the same in the
> V10 patch attached.
> Thoughts?
>
I'm still not happy about changing so many error messages.
Some of the changes might be OK, but aren't strictly necessary. For example:
C
On Tue, 13 Jul 2021 at 15:30, vignesh C wrote:
>
> On Tue, Jul 13, 2021 at 4:25 PM Dean Rasheed wrote:
> >
> > As it stands, the improvements from (3) seem quite worthwhile. Also,
> > the patch saves a couple of hundred lines of code, and for me an
> > optimi
On Mon, 31 May 2021 at 15:10, vignesh C wrote:
>
> On Sat, May 29, 2021 at 9:20 PM Bharath Rupireddy
> wrote:
> >
> > Thanks. PSA v3 patch.
>
> Thanks for the updated patch, the changes look good to me.
>
Hi,
Having pushed [1], I started looking at this, and I think it's mostly
in good shape.
On Fri, 16 Jul 2021 at 06:40, Bharath Rupireddy
wrote:
>
> 1) Duplicate option check for "FROM" option is unnecessary and will be
> a dead code. Because the syntaxer anyways would catch if FROM is
> specified more than once, something like CREATE COLLATION mycoll1 FROM
> FROM "C";.
Hmm, it is pos
On Fri, 16 Jul 2021 at 10:26, Bharath Rupireddy
wrote:
>
> Thanks. The v5 patch LGTM.
OK, I'll push that in a while.
> Comment on errorConflictingDefElem:
> I think that the message in errorConflictingDefElem should say
> <>. I'm not sure why it
> wasn't done. Almost, all the cases where errorCo
On Fri, 16 Jul 2021 at 12:17, Dean Rasheed wrote:
>
> On Fri, 16 Jul 2021 at 10:26, Bharath Rupireddy
> wrote:
> >
> > Thanks. The v5 patch LGTM.
>
> OK, I'll push that in a while.
>
Pushed, with some additional tidying up.
In particular, I decided it was nea
On Sat, 17 Jul 2021 at 05:24, Bharath Rupireddy
wrote:
>
> I also think that if it is specified as CREATE FUNCTION ... STRICT
> STRICT, CREATE FUNCTION ... CALLED ON NULL INPUT RETURNS NULL ON NULL
> INPUT etc. isn't the syntaxer catching that error while parsing the
> SQL text, similar to CREATE
On Wed, 21 Jul 2021 at 03:48, Bruce Momjian wrote:
>
> this example now gives me concern:
>
> SELECT INTERVAL '1.06 months 1 hour';
>interval
> ---
> 1 mon 2 days 01:00:00
>
> Notice that it rounds the '1.06 months' to '1 mon 2 days', ra
On Tue, 20 Jul 2021 at 10:17, Yugo NAGATA wrote:
>
> This patch fixes numeric_power() to handle negative bases correctly and not
> to raise an error "cannot take logarithm of a negative number", as well as a
> bug that a result whose values is almost zero is incorrectly returend as 1.
> The previo
On Tue, 20 Jul 2021 at 19:28, Tomas Vondra
wrote:
>
> > The new code in statext_is_compatible_clause_internal() is a little
> > hard to follow because some of the comments aren't right
>
> I ended up doing something slightly different - examine_opclause_args
> now "returns" a list of expressions,
On Thu, 22 Jul 2021 at 06:13, Yugo NAGATA wrote:
>
> Thank you for updating the patch. I am fine with the additional comments.
> I don't think there is any other problem left, so I marked it
> Ready-for-Committers.
>
Thanks for looking. Barring any further comments, I'll push this in a few days.
On Wed, 21 Jul 2021 at 22:33, Tom Lane wrote:
>
> I took a brief look at this and have a couple of quick suggestions:
>
Thanks for looking at this!
> * As you mention, keeping some spare bits in the typmod might come
> in handy some day, but as given this patch isn't really doing so.
> I think i
On Fri, 23 Jul 2021 at 16:50, Tom Lane wrote:
>
> OK, I've now studied this more closely, and have some additional
> nitpicks:
>
> * I felt the way you did the documentation was confusing. It seems
> better to explain the normal case first, and then describe the two
> extended cases.
OK, that lo
On Wed, 28 Jul 2021 at 00:08, John W Higgins wrote:
>
> It's nice to envision all forms of fancy calculations. But the fact is that
>
> '1.5 month'::interval * 2 != '3 month"::interval
>
That's not exactly true. Even without the patch:
SELECT '1.5 month'::interval * 2 AS product,
'3 month
On Thu, 22 Jul 2021 at 16:19, Dean Rasheed wrote:
>
> On Thu, 22 Jul 2021 at 06:13, Yugo NAGATA wrote:
> >
> > Thank you for updating the patch. I am fine with the additional comments.
> > I don't think there is any other problem left, so I marked it
> > R
While testing the numeric_power() patch in [1], I found this problem
trying to use to_char() to format very small numbers:
SELECT to_char(1.2e-1001, '9.9'); -- OK
to_char
1.2e-1001
SELECT to_char(1.2e-1002, '9.9'); -- fails
ERROR: division by zero
It turns out that the
On Fri, 30 Jul 2021 at 08:26, Dean Rasheed wrote:
>
> SELECT to_char(1.2e-1002, '9.9'); -- fails
> ERROR: division by zero
>
> I think the simplest
> solution is to just introduce a new local function, as in the attached
> patch. This directly constructs 10^n,
On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
>
> It looks like castoroides is not happy with this patch:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides&dt=2021-08-01%2008%3A52%3A43
>
> Maybe there's some hidden C99 dependency in what you did?
> Although pademelon, which is
On Fri, 6 Aug 2021 at 03:58, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
> >> It looks like castoroides is not happy with this patch:
> >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides&dt=2
On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
>
> > I guess the best thing to do is just test the value against
> > PG_INT32_MIN/MAX, which is what int84() does. There are 2 other places
> > in numeric.c that use similar code to check for int16/32 overflow, so
> > it's possible that they're broken
On Fri, 6 Aug 2021 at 21:26, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
> >> Looks plausible by eyeball (I've not tested).
>
> > So, I have back-branch patches for this ready to go. The question is,
> > is i
On Wed, 11 Aug 2021 at 00:05, Tomas Vondra
wrote:
>
> So with the statistics, the estimate gets a bit worse. The reason is
> fairly simple - if you look at the two parts of the OR clause, we get this:
>
> clause actualno statswith stats
>
On Thu, 9 May 2024 at 05:03, Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
I noticed a couple more things. This item:
Add functions to convert integers to hex and
On Tue, 19 Mar 2024 at 11:53, Daniel Gustafsson wrote:
>
> I did notice a few mistakes in the --filter
> documentation portion for other keywords but that's unrelated to this patch,
> will fix them once this is in to avoid conflicts.
>
Attached is a patch for the --filter docs, covering the omiss
On Sat, 8 Jun 2024 at 19:39, Ayush Vatsa wrote:
>
> > Attached is a patch for the --filter docs, covering the omissions I can see.
> Thanks Dean for working on this.
> I have reviewed the changes and they look good to me.
>
Thanks for checking. I have committed this now.
Regards,
Dean
On Sun, Jun 23, 2024 at 09:00:29AM +0200, Joel Jacobson wrote:
> Attached, rebased version of the patch that implements the Karatsuba
> algorithm in numeric.c's mul_var().
>
Something to watch out for is that not all callers of mul_var() want
an exact result. Several internal callers request an a
On Sat, 29 Jun 2024 at 16:25, Tom Lane wrote:
>
> Dean Rasheed writes:
> > There's another complication though (if the threshold is made
> > configurable): the various numeric functions that use mul_var() are
> > immutable, which means that the results from the Karat
Attached is a patch adding support for the gamma and log-gamma
functions. See, for example:
https://en.wikipedia.org/wiki/Gamma_function
I think these are very useful general-purpose mathematical functions.
They're part of C99, and they're commonly included in other
mathematical libraries, such a
On Mon, 1 Jul 2024 at 20:56, Joel Jacobson wrote:
>
> Below is a more realistic benchmark
>
> CREATE TABLE bench_mul_var (num1 numeric, num2 numeric);
>
> INSERT INTO bench_mul_var (num1, num2)
> SELECT random(0::numeric,1e8::numeric), random(0::numeric,1e8::numeric) FROM
> generate_series(1,1e8)
On Mon, 1 Jul 2024 at 16:04, Alvaro Herrera wrote:
>
> On 2024-Jul-01, Stepan Neretin wrote:
>
> > I have one notice:
> > ERROR: value out of range: overflow. I think we need to add information
> > about the available ranges in the error message
>
> I think this is a project of its own. The erro
On Tue, 2 Jul 2024 at 08:50, Joel Jacobson wrote:
>
> On Tue, Jul 2, 2024, at 00:19, Dean Rasheed wrote:
>
> > Attachments:
> > * optimize-numeric-mul_var-small-var1-arbitrary-var2.patch.txt
>
Shortly after posting that, I realised that there was a small bug. This
On Sun, 30 Jun 2024 at 11:22, Joel Jacobson wrote:
>
> The surprising realization here is that there are actually (var1ndigits,
> var2ndigits)
> combinations where *only* doing mul_var_karatsuba_half() recursively
> all the way down to schoolbook *is* a performance win,
> even though we don't do
On Sun, 30 Jun 2024 at 11:22, Joel Jacobson wrote:
>
> On Sat, Jun 29, 2024, at 14:22, Dean Rasheed wrote:
>
> > But why just split it into two pieces? That will just lead
> > to a lot of unnecessary recursion for very unbalanced inputs. Instead,
> > why not split the
On Tue, 2 Jul 2024 at 11:23, Joel Jacobson wrote:
>
> Just to be able to verify mul_var() is working as expected when
> rscale is less than the full result, I've added a numeric_mul_patched()
> function that takes a third rscale_adjustment parameter:
Yeah, we could expose such a function, and may
On Tue, 2 Jul 2024 at 20:55, Joel Jacobson wrote:
>
> Interesting, I actually think there is a bug in the normal mul_var() code.
> Found a case that rounds down, when it should round up:
>
> Calling mul_var() with:
> var1=51.2945442386599
> var2=0.828548712212
> rscale=0
>
> returns 42, but I thin
On Tue, 2 Jul 2024 at 21:10, Joel Jacobson wrote:
>
> I found the bug in the case 3 code,
> and it turns out the same type of bug also exists in the case 2 code:
>
> case 2:
> newdig = (int) var1digits[1] *
> var2digits[res_ndigits - 4];
>
>
On Wed, 3 Jul 2024 at 08:36, Joel Jacobson wrote:
>
> Hello hackers,
>
> I have discovered a peculiar behavior in mul_var() when it is called with
> rscale=0, but the input variables have many decimal digits, resulting in a
> product with a .5 decimal part. Given that no decimals are requested by
On Wed, 3 Jul 2024 at 14:49, Joel Jacobson wrote:
>
> Hmm, I don't see how the case 2 code can be correct?
> If, like you say, res_ndigits can't be less than 3, that means it can be 3,
> right?
> And if res_ndigits=3 then `var2digits[res_ndigits - 4]` would try to access
> `var2digits[-1]`.
>
A
On Wed, 3 Jul 2024 at 21:45, Joel Jacobson wrote:
>
> > On Wed, Jul 3, 2024, at 20:57, Dean Rasheed wrote:
> >> I wouldn't expect it to ever be off by more than 1
> >
> > OK, so then the cases I found where it was off by 2 for the mul_var_int()
> > pat
On Fri, 5 Jul 2024 at 12:56, Joel Jacobson wrote:
>
> Interesting you got so bad bench results for v6-mul_var_int64.patch
> for var1ndigits=4, that patch is actually the winner on AMD Ryzen 9 7950X3D.
Interesting.
> On Intel Core i9-14900K the winner is
> v6-optimize-numeric-mul_var-small-var1-
On Fri, 5 Jul 2024 at 18:37, Joel Jacobson wrote:
>
> On Fri, Jul 5, 2024, at 18:42, Joel Jacobson wrote:
> > Very nice, v7-optimize-numeric-mul_var-small-var1-arbitrary-var2.patch
> > is now the winner on all my CPUs:
>
> I thought it would be interesting to also measure the isolated effect
> on
In the numeric width_bucket() code, we currently do the following:
mul_var(&operand_var, count_var, &operand_var,
operand_var.dscale + count_var->dscale);
div_var(&operand_var, &bound2_var, result_var,
select_div_scale(&operand_var, &bound2_var), true);
if (cmp
The numeric round() and trunc() functions clamp the scale argument to
the range between +/- NUMERIC_MAX_RESULT_SCALE, which is +/- 2000.
That's a long way short of the actual allowed range of type numeric,
so they produce incorrect results when rounding/truncating more than
2000 digits before or af
On Mon, 8 Jul 2024 at 00:40, Joel Jacobson wrote:
>
> On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
> > I've also tidied up a bit by replacing all instances of SHRT_MAX with
> > a new constant NUMERIC_WEIGHT_MAX, whose name more accurately
> > describes the li
On Mon, 8 Jul 2024 at 11:08, Joel Jacobson wrote:
>
> LGTM.
>
Thanks for the review. I have pushed and back-patched this.
Regards,
Dean
On Sat, 6 Jul 2024 at 12:17, Joel Jacobson wrote:
>
> > I think this is good to go, so unless there are any further comments,
> > I plan to commit it soon.
>
> LGTM.
>
OK, I have committed this.
At the last minute, I changed the name of the new function to
mul_var_short() because "short" is prob
On Tue, 9 Jul 2024 at 10:11, Dean Rasheed wrote:
>
> OK, I have committed this.
>
Before considering the other patches to optimise for larger inputs, I
think it's worth optimising the existing mul_var() code as much as
possible.
One thing I noticed while testing the earlier p
On Sun, 7 Jul 2024 at 13:43, Joel Jacobson wrote:
>
> > SELECT hash_array(array_agg(width_bucket(op, b1, b2, c))) FROM t;
> > -- Result not changed by patch
>
> Same hash_array on all my three machines:
>
> > SELECT sum(width_bucket(op, b1, b2, c)) FROM t;
> > Time: 3658.962 ms (00:03.659) -- HEA
On Sun, 7 Jul 2024 at 20:46, Joel Jacobson wrote:
>
> This patch adds a mul_var_large() that is dispatched to from mul_var()
> for var1ndigits >= 8, regardless of rscale.
>
> -- var1ndigits == var2ndigits == 16384
> SELECT COUNT(*) FROM n_max WHERE product = var1 * var2;
> Time: 3191.145 ms (00:03
On Tue, 2 Jul 2024 at 11:18, Jim Jones wrote:
>
> When either minval or maxval exceeds int4 the function cannot be
> executed/found
>
> SELECT * FROM normal_rand_array(5, 10, 8, 42::bigint);
>
> ERROR: function normal_rand_array(integer, integer, integer, bigint)
> does not exist
> LINE 1: SELECT
On Wed, 12 Jul 2023 at 18:11, Alvaro Herrera wrote:
>
> v13, because a conflict was just committed to alter_table.sql.
>
> Here I also call out the relcache.c change by making it a separate
> commit. I'm likely to commit it that way, too. To recap: the change is
> to have a partitioned table's i
On Tue, 11 Jul 2023 at 21:43, Gurjeet Singh wrote:
>
> > > I think the name of function pg_merge_when_clause() can be improved.
> > > How about pg_merge_when_clause_ordinal().
> >
> > That's a bit of a mouthful, but I don't have a better idea right now.
> > I've left the names alone for now, in ca
On Thu, 13 Jul 2023 at 17:01, Jeff Davis wrote:
>
> MERGE can end up combining old and new values in a way that doesn't
> happen with INSERT/UPDATE/DELETE. For instance, a "MERGE ... RETURNING
> id" would return a mix of NEW.id (for INSERT/UPDATE actions) and OLD.id
> (for DELETE actions).
>
Righ
On Thu, 13 Jul 2023 at 17:43, Vik Fearing wrote:
>
> There is also the WITH ORDINALITY and FOR ORDINALITY examples.
>
True. I just think "number" is a friendlier, more familiar word than "ordinal".
> So perhaps pg_merge_when_clause_number() would
> > be a better name. It's still quite long, but
On Thu, 13 Jul 2023 at 20:14, Jeff Davis wrote:
>
> On Thu, 2023-07-13 at 18:01 +0100, Dean Rasheed wrote:
> > For some use cases, I can imagine allowing OLD/NEW.colname would mean
> > you wouldn't need pg_merge_action() (if the column was NOT NULL), so
> > I
>
On Wed, 19 Jul 2023 at 09:24, Masahiko Sawada wrote:
>
> > > 2) pg_strtoint32_safe() got substantially slower, mainly due
> > >to
> > > faff8f8e47f Allow underscores in integer and numeric constants.
> > > 6fcda9aba83 Non-decimal integer literals
> >
> > Agreed.
> >
> I have made some progress
On Thu, 20 Jul 2023 at 00:56, David Rowley wrote:
>
> I noticed that 6fcda9aba added quite a lot of conditions that need to
> be checked before we process a normal decimal integer string. I think
> we could likely do better and code it to assume that most strings will
> be decimal and put that cas
On Mon, 17 Jul 2023 at 20:43, Jeff Davis wrote:
>
> > > Maybe instead of a function it could be a special table reference
> > > like:
> > >
> > > MERGE ... RETURNING MERGE.action, MERGE.action_number, id, val?
> > >
> The benefits are:
>
> 1. It is naturally constrained to the right context. It
On Thu, 20 Jul 2023 at 16:31, Alvaro Herrera wrote:
>
> On 2023-Jul-13, Dean Rasheed wrote:
>
> > I see that it's already been discussed, but I don't like the fact that
> > there is no way to get hold of the new constraint names in psql. I
> > think for the p
On Thu, 20 Jul 2023 at 16:31, Alvaro Herrera wrote:
>
> On 2023-Jul-13, Dean Rasheed wrote:
>
> > Something else I noticed is that the result from "ALTER TABLE ...
> > ALTER COLUMN ... DROP NOT NULL" is no longer easily predictable -- if
> > there are multip
Something else I noticed: the error message from ALTER TABLE ... ADD
CONSTRAINT in the case of a duplicate constraint name is not very
friendly:
ERROR: duplicate key value violates unique constraint
"pg_constraint_conrelid_contypid_conname_index"
DETAIL: Key (conrelid, contypid, conname)=(16540,
On Mon, 24 Jul 2023 at 17:42, Alvaro Herrera wrote:
>
> On 2023-Jul-24, Dean Rasheed wrote:
>
> > Something else I noticed: the error message from ALTER TABLE ... ADD
> > CONSTRAINT in the case of a duplicate constraint name is not very
> > friendly:
> >
> &g
On Tue, 25 Jul 2023 at 13:36, Alvaro Herrera wrote:
>
> Okay then, I've made these show up in the footer of \d+. This is in
> patch 0003 here. Please let me know what do you think of the regression
> changes.
>
The new \d+ output certainly makes testing and reviewing easier,
though I do underst
On Tue, 1 Aug 2023 at 13:55, David Rowley wrote:
>
> I tried adding the "at least 1 digit check" by adding an else { goto
> slow; } in the above code, but it seems to generate slower code than
> just checking if (unlikely(ptr == s)) { goto slow; } after the loop.
>
That check isn't quite right, b
On Tue, 1 Aug 2023 at 15:01, David Rowley wrote:
>
> Here's a patch with an else condition when the first digit check fails.
>
> master + fastpath4.patch:
> latency average = 1579.576 ms
> latency average = 1572.716 ms
> latency average = 1563.398 ms
>
> (appears slightly faster than fastpath3.pat
On Fri, 4 Aug 2023 at 19:10, Alvaro Herrera wrote:
>
> On 2023-Jul-28, Alvaro Herrera wrote:
>
> > To avoid that, one option would be to make this NN constraint
> > undroppable ... but I don't see how. One option might be to add a
> > pg_depend row that links the NOT NULL constraint to its PK co
On Sat, 5 Aug 2023 at 18:37, Alvaro Herrera wrote:
>
> Yeah, something like that. However, if the child had a NOT NULL
> constraint of its own, then it should not be deleted when the
> PK-on-parent is, but merely marked as no longer inherited. (This is
> also what happens with a straight NOT NUL
On Mon, 7 Aug 2023 at 19:49, Christoph Heiss wrote:
>
> On Fri, Jan 06, 2023 at 12:18:44PM +, Dean Rasheed wrote:
> > Hmm, I don't think we should be offering "check_option" as a tab
> > completion for CREATE VIEW at all, since that would encourage users t
On Fri, 11 Aug 2023 at 14:54, Alvaro Herrera wrote:
>
> Right, in the end I got around to that point of view. I abandoned the
> idea of adding these dependency links, and I'm back at relying on the
> coninhcount/conislocal markers. But there were a couple of bugs in the
> accounting for that, so
On Thu, 17 Aug 2023 at 16:26, Nathan Bossart wrote:
>
> Works for me. I did it that way in v7.
>
I note that there are no tests for negative inputs.
Doing a quick test, shows that this changes the current behaviour,
because all inputs are now treated as 64-bit:
HEAD:
select to_hex((-1234)::in
On Sun, 20 Aug 2023 at 16:25, Nathan Bossart wrote:
>
> On Sat, Aug 19, 2023 at 08:35:46AM +0100, Dean Rasheed wrote:
>
> > The way that negative inputs are handled really should be documented,
> > or at least it should include a couple of examples.
>
> I used your su
On Mon, 21 Aug 2023 at 20:15, Nathan Bossart wrote:
>
> I added some examples for negative inputs.
>
> I renamed it to to_bin().
>
> I reordered the functions in the docs.
>
OK, cool. This looks good to me.
Regards,
Dean
On Tue, 25 Jul 2023 at 21:46, Gurjeet Singh wrote:
>
> There seems to be other use cases which need us to invent a method to
> expose a command-specific alias. See Tatsuo Ishii's call for help in
> his patch for Row Pattern Recognition [1].
>
I think that's different though, because in that examp
Updated version attached, fixing an uninitialized-variable warning
from the cfbot.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..7f65f6e
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml/dml.sgml
@@ -283,10 +283,15 @@ DELETE FROM products
On Tue, 16 Apr 2024 at 11:35, Richard Guo wrote:
>
> On Tue, Apr 16, 2024 at 5:48 PM Aleksander Alekseev
> wrote:
>>
>> Oversight of 0294df2f1f84 [1].
>>
>> [1]:
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0294df2f1f84
>
> +1. I think this change improves the code quality
On Thu, 18 Apr 2024 at 13:00, Aleksander Alekseev
wrote:
>
> Fair point. PFA the alternative version of the patch.
>
Thanks. Committed.
Regards,
Dean
On Mon, 22 Apr 2024 at 06:04, Michael Paquier wrote:
>
> On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
>
On Tue, 14 May 2024 at 07:43, Michael Paquier wrote:
>
> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> > Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
> > the parameter number with atol which stops at the underscore. That's a
> > regression in faff8f8e4
On Thu, 16 May 2024 at 15:15, Peter Eisentraut wrote:
>
> I wonder if we can avoid making MERGE_ACTION a keyword.
>
Yeah, there was a lot of back and forth on this point on the original
thread, and I'm still not sure which approach is best.
> I think we could parse it initially as a function and
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 good to me on a quick read-through.
I'll take a closer look next week, after the beta release, since it's
a v16+ b
On Thu, 23 May 2024 at 04:26, David Rowley wrote:
>
> On Sun, 19 May 2024 at 15:20, David Rowley wrote:
> >
> > I noticed that PlannedStmt.hasReturning and hasModifyingCTE have an
> > outdated comment now that MERGE supports RETURNING (per commit
> > c649fa24a)
> >
> > i.e. these two:
> >
> > > b
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
401 - 500 of 649 matches
Mail list logo
