On Fri, 3 Mar 2023 at 11:23, David Rowley wrote:
>
> On Fri, 3 Mar 2023 at 09:32, Dean Rasheed wrote:
> > Hmm, I think it would be easier to just have a separate table for
> > pg_size_bytes(), rather than reusing pg_size_pretty()'s table.
>
> Maybe that's worthwhile if w
On Thu, 2 Mar 2023 at 19:58, David Rowley wrote:
>
> I think I'd prefer to see the size_bytes_unit_alias struct have an
> index into size_pretty_units[] array. i.e:
>
> struct size_bytes_unit_alias
> {
> const char *alias; /* aliased unit name */
> const int unit_index; /* corresponding
Now that we have random_normal(), it seems like it would be useful to
add the error functions erf() and erfc(), which I think are
potentially useful to the people who will find random_normal() useful,
and possibly others.
An immediate use for erf() is that it allows us to do a
Kolmogorov-Smirnov
On Fri, 24 Feb 2023 at 05:46, Dean Rasheed wrote:
>
> Rebased version attached.
>
Another rebase.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..ff2a827
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml/dml.sgml
@@ -283,1
On Fri, 24 Feb 2023 at 09:28, Dean Rasheed wrote:
>
> On Fri, 24 Feb 2023 at 08:56, Alvaro Herrera wrote:
> >
> > I assume you're proposing to back-patch this.
>
> Yes. Will do.
>
Done.
Regards,
Dean
Doc: Miscellaneous doc updates for MERGE.
Update a few places in the documentation that should mention MERGE
among the list of applicable commands. In a couple of places, a
slightly more detailed description of what happens for MERGE seems
appropriate.
Reviewed by Alvaro Herrera.
Discussion:
Doc: Miscellaneous doc updates for MERGE.
Update a few places in the documentation that should mention MERGE
among the list of applicable commands. In a couple of places, a
slightly more detailed description of what happens for MERGE seems
appropriate.
Reviewed by Alvaro Herrera.
Discussion:
, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all
, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all
, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all
, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all
, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all
, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all
On Fri, 24 Feb 2023 at 08:56, Alvaro Herrera wrote:
>
> Agreed. Your patch looks good to me.
>
> I was confused for a bit about arch-dev.sgml talking about ModifyTable
> when perform.sgml talks about Insert/Update et al; I thought at first
> that one or the other was in error, so I checked. It
Attached is a patch fixing a few doc omissions for MERGE.
I don't think that it's necessary to update every place that could
possibly apply to MERGE, but there are a few places where we give a
list of commands that may be used in a particular context, and I think
those should mention MERGE, if it
On Tue, 7 Feb 2023 at 10:56, Dean Rasheed wrote:
>
> Attached is a more complete patch
>
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..ff2a827
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml
points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/
points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/
points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/
points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/
points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/
points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
Branch
--
master
Details
---
https://git.postgresql.org/
On Mon, 20 Feb 2023 at 19:49, Dean Rasheed wrote:
>
> On Mon, 20 Feb 2023 at 19:39, Tom Lane wrote:
> >
> > Ugh. Grepping around, it looks like pltcl_process_SPI_result
> > is missing a case for SPI_OK_MERGE as well.
>
> Yes, I was about to post a patch for
Add missing support for the latest SPI status codes.
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
Add missing support for the latest SPI status codes.
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
Add missing support for the latest SPI status codes.
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
Add missing support for the latest SPI status codes.
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
Add missing support for the latest SPI status codes.
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
Add missing support for the latest SPI status codes.
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
On Mon, 20 Feb 2023 at 16:18, Dean Rasheed wrote:
>
> As part of the MERGE RETURNING patch I noticed a suspicious Assert()
> in ExecInitPartitionInfo() that looked like it needed updating for
> MERGE.
>
> After more testing, I can confirm that this is indeed a pre-existi
Fix Assert failure for MERGE into a partitioned table with RLS.
In ExecInitPartitionInfo(), the Assert when building the WITH CHECK
OPTION list for the new partition assumed that the command would be an
INSERT or UPDATE, but it can also be a MERGE. This can be triggered by
a MERGE into a
Fix Assert failure for MERGE into a partitioned table with RLS.
In ExecInitPartitionInfo(), the Assert when building the WITH CHECK
OPTION list for the new partition assumed that the command would be an
INSERT or UPDATE, but it can also be a MERGE. This can be triggered by
a MERGE into a
On Tue, 21 Feb 2023 at 09:34, Alvaro Herrera wrote:
>
> > I think the best fix is to have ExecMergeMatched() pass canSetTag =
> > false to ExecUpdateAct(), so that ExecMergeMatched() takes
> > responsibility for updating estate->es_processed in all cases.
>
> Sounds sensible.
>
I decided it was
Fix MERGE command tag for cross-partition updates.
This ensures that the row count in the command tag for a MERGE is
correctly computed. Previously, if MERGE updated a partitioned table,
the row count would be incorrect if any row was moved to a different
partition, since such updates were
Fix MERGE command tag for cross-partition updates.
This ensures that the row count in the command tag for a MERGE is
correctly computed. Previously, if MERGE updated a partitioned table,
the row count would be incorrect if any row was moved to a different
partition, since such updates were
Another one noticed in the MERGE RETURNING patch -- this allows PL/Tcl
to execute MERGE (i.e., don't fail when SPI returns SPI_OK_MERGE). I'm
not sure if anyone uses PL/Tcl anymore, but it's a trivial fix,
probably not worth a regression test case.
Regards,
Dean
diff --git a/src/pl/tcl/pltcl.c
On Mon, 20 Feb 2023 at 19:39, Tom Lane wrote:
>
> Ugh. Grepping around, it looks like pltcl_process_SPI_result
> is missing a case for SPI_OK_MERGE as well.
>
Yes, I was about to post a patch for that too. That's the last case
that I found, looking around.
Regards,
Dean
Another one noticed from the MERGE RETURNING patch -- the switch
statement in SPI_result_code_string() is missing cases for
SPI_OK_TD_REGISTER and SPI_OK_MERGE.
The SPI_OK_TD_REGISTER case goes back all the way, so I suppose it
should be back-patched to all supported branches, though evidently
As part of the MERGE RETURNING patch I noticed a suspicious Assert()
in ExecInitPartitionInfo() that looked like it needed updating for
MERGE.
After more testing, I can confirm that this is indeed a pre-existing
bug, that can be triggered using MERGE into a partitioned table that
has RLS enabled
Playing around with MERGE some more, I noticed that the command tag
row count is wrong if it does a cross-partition update:
CREATE TABLE target (a int, b int) PARTITION BY LIST (b);
CREATE TABLE target_p1 PARTITION OF target FOR VALUES IN (1);
CREATE TABLE target_p2 PARTITION OF target FOR VALUES
On Mon, 20 Feb 2023 at 08:03, Joel Jacobson wrote:
>
> On Mon, Feb 20, 2023, at 08:38, Michael Paquier wrote:
> > Perhaps you should register this patch to the commit of March? Here
> > it is:
> > https://commitfest.postgresql.org/42/
>
> Thanks, done.
>
I have been testing this a bit, and I
On Mon, 23 Jan 2023 at 16:54, Dean Rasheed wrote:
>
> On Sun, 22 Jan 2023 at 19:08, Alvaro Herrera wrote:
> >
> > Regarding mas_action_idx, I would have thought that it belongs in
> > MergeAction rather than MergeActionState. After all, you determine i
On Sat, 21 Jan 2023 at 14:18, Ted Yu wrote:
>
> On Sat, Jan 21, 2023 at 3:05 AM Dean Rasheed wrote:
>>
>> Rebased version, following 8eba3e3f02 and 5d29d525ff.
>>
Another rebased version attached.
> In transform_MERGE_to_join :
>
> +
On Thu, 2 Feb 2023 at 22:40, Peter Eisentraut
wrote:
>
> On 31.01.23 17:09, Dean Rasheed wrote:
> > On Tue, 31 Jan 2023 at 15:28, Peter Eisentraut
> > wrote:
> >>
> >> Did you have any thoughts about what to do with the float types? I
> >> gu
is allowed between any 2 digits, or immediately
after the base prefix indicator of non-decimal integers, per SQL:202x
draft.
Peter Eisentraut and Dean Rasheed
Discussion:
https://postgr.es/m/84aae844-dc55-a4be-86d9-4f0fa405cc97%40enterprisedb.com
Branch
--
master
Details
---
https
ch to v14, where it was introduced.
Dean Rasheed, reviewed by Tom Lane.
Discussion:
https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/86bfbeab4f439ad527318d9edeb3c71ea4
ch to v14, where it was introduced.
Dean Rasheed, reviewed by Tom Lane.
Discussion:
https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/4f74741a5cea38228fdb0fb2967fa2137e
ch to v14, where it was introduced.
Dean Rasheed, reviewed by Tom Lane.
Discussion:
https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/b2d47928908d7a99b8e39198d0e8e9e0cb2b024b
On Fri, 3 Feb 2023 at 01:18, Tom Lane wrote:
>
> Dean Rasheed writes:
>
> > 1). It doesn't work if log10val2 < 0, because then m < 0, and it
> > doesn't multiply by the remainder. And it then throws an overflow
> > error, because result.dscale comes out wrong w
On Thu, 2 Feb 2023 at 15:15, Tom Lane wrote:
>
> Looking at this diff made me wonder why the static pow10[] array
> isn't marked "const"?
>
Good point.
However, looking more closely, I think this function is more or less
completely broken:
1). It doesn't work if log10val2 < 0, because then m <
On Thu, 2 Feb 2023 at 06:40, Tom Lane wrote:
>
> Noah Misch writes:
> > Regarding the concern about a pre-receive hook blocking an emergency push,
> > the
> > hook could approve every push where a string like "pgindent: no" appears in
> > a
> > commit message within the push. You'd still want
On Tue, 31 Jan 2023 at 21:59, Joel Jacobson wrote:
>
> Nice, you managed to simplify it even further.
> I think the comment and the code now are crystal clear together.
>
> I've tested it successfully, test report attached.
>
Cool. Thanks for testing.
Committed.
Regards,
Dean
Ensure that numeric.c compiles with other NBASE values.
As noted in the comments, support for different NBASE values is really
only of historical interest, but as long as we're keeping it, we might
as well make sure that it compiles.
Joel Jacobson
Discussion:
the computation in that case.
Joel Jacobson and Dean Rasheed
Discussion:
https://postgr.es/m/06712c29-98e9-43b3-98da-f234d81c6e49%40app.fastmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0736fc1ceb0659a9f73699910ac56603336daeee
Modified Files
On Wed, 1 Feb 2023 at 12:12, Alvaro Herrera wrote:
>
> I had tried to tie these relations using WITH ORDINALITY, but the only
> way I could think of (array_agg to then unnest() WITH ORDINALITY) was
> even uglier than what I already had. So yeah, I think it might be
> useful if we had a way to
On Tue, 31 Jan 2023 at 15:05, Joel Jacobson wrote:
>
> I also think the performance impact no matter how small isn't worth it,
> but a comment based on your comments would be very valuable IMO.
>
> Below is an attempt at summarising your text, and to avoid the performance
> impact,
> maybe an
On Tue, 31 Jan 2023 at 15:28, Peter Eisentraut
wrote:
>
> Did you have any thoughts about what to do with the float types? I
> guess we could handle those in a separate patch?
>
I was assuming that we'd do nothing for float types, because anything
we did would necessarily impact their
On Tue, 31 Jan 2023 at 08:00, Joel Jacobson wrote:
>
> I think this is what we want:
>
> if (arg.weight < 0)
> sweight = (arg.weight + 1) * DEC_DIGITS / 2 - 1;
> else
> sweight = arg.weight * DEC_DIGITS / 2 + 1;
>
That's still not right. If you
that could be relaxed, by allowing some generated
columns to be skipped for a MERGE without an INSERT action, but it's
not clear that it's worth the effort.
Noticed while investigating bug #17759. Back-patch to v15, where MERGE
was added.
Dean Rasheed, reviewed by Tom Lane.
Discussion:
https
that could be relaxed, by allowing some generated
columns to be skipped for a MERGE without an INSERT action, but it's
not clear that it's worth the effort.
Noticed while investigating bug #17759. Back-patch to v15, where MERGE
was added.
Dean Rasheed, reviewed by Tom Lane.
Discussion:
https
On Sat, 28 Jan 2023 at 22:14, Joel Jacobson wrote:
>
> I found what appears to be a small harmless error in numeric.c,
> that seems worthwhile to fix only because it's currently causes confusion.
>
Shrug. Looking at git blame, it's been like that for about 20 years,
and I wasn't aware of it
I spent a little time investigating bug #17759 [1] in more detail.
Initially, I thought that it had been fixed by 3f7836ff65, but it
turns out that's not the case.
[1]
https://www.postgresql.org/message-id/17759-e76d9bece1b5421c%40postgresql.org
The immediate cause of the bug was that, before
On Wed, 25 Jan 2023 at 21:43, Peter Eisentraut
wrote:
>
> On 24.01.23 14:10, Dean Rasheed wrote:
> > I also think it might be useful for it to gain a couple of boolean options:
> >
> > 1). An option to output a signed value (defaulting to false, to
> > preserve the c
On Wed, 25 Jan 2023 at 10:57, Aleksander Alekseev
wrote:
>
> > Of course there is. This is easy to code in C using unsigned ints,
> > without resorting to abs() (yes, I'm aware that abs() is undefined for
> > INT_MIN).
>
> So in your opinion what is the expected result of to_hex(INT_MIN,
>
On Wed, 25 Jan 2023 at 09:02, Aleksander Alekseev
wrote:
>
> > I don't see how a couple of extra arguments will expand to hundreds.
>
> Maybe I was exaggerating, but the point is that adding extra flags for
> every possible scenario is a disadvantageous approach in general.
> There is no need to
On Wed, 18 Jan 2023 at 15:25, Justin Pryzby wrote:
>
> TBH, I think the best approach is what I did in:
> 0001-report-top-parent-progress-for-CREATE-INDEX.txt
>
> That's a minimal patch, ideal for backpatching.
>
> ..which defines/clarifies that the progress reporting is only for
> *direct*
On Tue, 24 Jan 2023 at 13:43, Aleksander Alekseev
wrote:
>
> Adding extra arguments for something the user can implement
> (him/her)self doesn't seem to be a great idea. With this approach we
> may end up with hundreds of arguments one day.
>
I don't see how a couple of extra arguments will
I only recently realised that to_hex() converts its input to unsigned
before converting it to hex (something that's not mentioned in the
docs):
to_hex(-1) ->
I think that's something that some users might find surprising,
especially if they were expecting to be able to use it to
On Tue, 24 Jan 2023 at 00:47, Ranier Vilela wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
> Hi
On Mon, 23 Jan 2023 at 20:00, Joel Jacobson wrote:
>
> Nice! This also simplifies when dealing with non-negative integers
> represented as byte arrays,
> common in e.g. cryptography code.
>
Ah, interesting. I hadn't thought of that use-case.
> create function numeric_from_bytes(bytea) returns
On Wed, 4 Jan 2023 at 09:28, Dean Rasheed wrote:
>
> In addition, I think that strip_underscores() could then go away if
> numeric_in() were made to handle underscores.
>
> Essentially then, that would move all responsibility for parsing
> underscores and non-decimal intege
Add non-decimal integer support to type numeric.
This enhances the numeric type input function, adding support for
hexadecimal, octal, and binary integers of any size, up to the limits
of the numeric type.
Since 6fcda9aba8, such non-decimal integers have been accepted by the
parser as integer
On Sun, 22 Jan 2023 at 19:08, Alvaro Herrera wrote:
>
> > diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
> > new file mode 100644
> > index e34f583..aa3cca0
> > --- a/src/backend/commands/copy.c
> > +++ b/src/backend/commands/copy.c
> > @@ -274,12 +274,6 @@
On Mon, 23 Jan 2023 at 15:55, Peter Eisentraut
wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
>
&
On Sun, 22 Jan 2023 at 22:49, Joel Jacobson wrote:
>
> Many thanks for feedback. Nice catch! New patch attached.
>
Cool, that resolves the performance issues I was seeing for smaller
divisors (which also had a noticeable impact on the numeric_big
regression test).
After some more testing, the
On Mon, 23 Jan 2023 at 05:06, John Naylor wrote:
>
> According to Agner's instruction tables [1], integer division on Skylake (for
> example) has a latency of 26 cycles for 32-bit operands, and 42-95 cycles for
> 64-bit.
>
> [1] https://www.agner.org/optimize/instruction_tables.pdf
>
Thanks,
Optimise numeric division for 3 and 4 base-NBASE digit divisors.
On platforms with 128-bit integer support, introduce a new function
div_var_int64(), along the same lines as div_var_int() added in
d1b307eef2 for divisors with 1 or 2 base-NBASE digits, and use it to
speed up div_var() and
On Sun, 22 Jan 2023 at 15:41, Joel Jacobson wrote:
>
> On Sun, Jan 22, 2023, at 11:06, Dean Rasheed wrote:
> > Seems like a reasonable idea, with some pretty decent gains.
> >
> > Note, however, that for a divisor having fewer than 5 or 6 digits,
> > it's now sig
On Sun, 22 Jan 2023 at 13:42, Joel Jacobson wrote:
>
> Hi,
>
> On platforms where we support 128bit integers, we could accelerate division
> when the number of digits in the divisor is larger than 8 and less than or
> equal to 16 digits, i.e. when the divisor that fits in a 64-bit integer but
>
On Mon, 9 Jan 2023 at 17:44, Dean Rasheed wrote:
>
> On Mon, 9 Jan 2023 at 16:23, Vik Fearing wrote:
> >
> > Bikeshedding here. Instead of Yet Another WITH Clause, could we perhaps
> > make a MERGING() function analogous to the GROUPING() function that goes
> > wit
On Tue, 10 Jan 2023 at 14:43, Dean Rasheed wrote:
>
> Rebased version attached.
>
Rebased version, following 8eba3e3f02 and 5d29d525ff.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index b87ad5c..1482ede
--- a/doc/src/sgml/mvcc.sgml
On Wed, 18 Jan 2023 at 09:49, David Rowley wrote:
>
> On Wed, 18 Jan 2023 at 22:37, Richard Guo wrote:
> > I'm still confused that when the same scenario happens with ORDER BY in
> > an aggregate function, like in query 1, the result is different in that
> > we would get an unsorted output.
> >
On Wed, 11 Jan 2023 at 05:24, David Rowley wrote:
>
> I'm wondering if 1349d279 should have just never opted to presort
> Aggrefs which have volatile functions so that the existing behaviour
> of unordered output is given always and nobody is fooled into thinking
> this works correctly only to be
Regards,
Dean
From f129bcdaeaaa62d8ddaf6a8e6441183f46097687 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Fri, 13 Jan 2023 09:20:17 +
Subject: [PATCH 1/2] Add non-decimal integer support to type numeric.
This enhances the numeric type input function, adding support for
hexadecimal, octal, and binary integ
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index b87ad5c..1482ede
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -396,8 +396,8 @@
originally matched appears later in the list of actions.
On the
On Mon, 2 Jan 2023 at 12:13, Dean Rasheed wrote:
>
> Re-reading my latest MERGE patch, I realised there is a trivial,
> pre-existing bug in the check for unreachable WHEN clauses, which
> means it won't spot an unreachable WHEN clause if it doesn't have an
> AND condition.
>
&g
Fix MERGE's test for unreachable WHEN clauses.
The former code would only detect an unreachable WHEN clause if it had
an AND condition. Fix, so that unreachable unconditional WHEN clauses
are also detected.
Back-patch to v15, where MERGE was added.
Discussion:
Fix MERGE's test for unreachable WHEN clauses.
The former code would only detect an unreachable WHEN clause if it had
an AND condition. Fix, so that unreachable unconditional WHEN clauses
are also detected.
Back-patch to v15, where MERGE was added.
Discussion:
On Tue, 3 Jan 2023 at 12:30, vignesh C wrote:
>
> The patch does not apply on top of HEAD as in [1], please post a rebased
> patch:
>
This is because 0001 has been committed.
Re-uploading 0002, to keep the CF-bot happy.
Reviewing 0002...
I'm not entirely convinced that the PartialMatches()
On Tue, 10 Jan 2023 at 08:33, Dean Rasheed wrote:
>
> The rest looks good to me, except there's a random non-ASCII character
> instead of a hyphen in "Kolmogorov-Smirnov" (because I copy-pasted the
> name from some random website).
>
Oh, never mind. I see you already fi
While doing some random testing, I noticed that the following is broken in HEAD:
SELECT COUNT(DISTINCT random()) FROM generate_series(1,10);
ERROR: ORDER/GROUP BY expression not found in targetlist
It appears to have been broken by 1349d279, though I haven't looked at
the details.
I'm
On Mon, 9 Jan 2023 at 23:38, Tom Lane wrote:
>
> I tried this on some 32-bit big-endian hardware (NetBSD on macppc)
> to verify my thesis that the results of random() are now machine
> independent. That part works, but the random_normal() tests didn't;
Ah yes, I wondered about that.
> I saw
On Mon, 9 Jan 2023 at 18:52, Tom Lane wrote:
>
> I pushed Paul's patch with the previously-discussed tests, but
> the more I look at random.sql the less I like it. I propose
> that we nuke the existing tests from orbit and replace with
> something more or less as attached.
Looks like a definite
On Mon, 9 Jan 2023 at 16:23, Vik Fearing wrote:
>
> Bikeshedding here. Instead of Yet Another WITH Clause, could we perhaps
> make a MERGING() function analogous to the GROUPING() function that goes
> with grouping sets?
>
> MERGE ...
> RETURNING *, MERGING('clause'), MERGING('action');
>
Hmm,
On Mon, 9 Jan 2023 at 15:26, Tom Lane wrote:
>
> Dean Rasheed writes:
> > So IMO all pseudorandom functions should share the same PRNG state and
> > seed-setting functions. That would mean they should all be in the same
> > (new) C file, so that the PRNG state can be k
On Sun, 8 Jan 2023 at 20:09, Isaac Morland wrote:
>
> Would it be useful to have just the action? Perhaps "WITH ACTION"? My idea is
> that this would return an enum of INSERT, UPDATE, DELETE (so is "action" the
> right word?). It seems to me in many situations I would be more likely to
> care
On Mon, 9 Jan 2023 at 00:20, Tom Lane wrote:
>
> This version seems committable to me, barring objections.
>
Whilst I have no objection to adding random_normal(), ISTM that we're
at risk of adding an arbitrary set of random functions without a clear
idea of where we'll end up, and how they'll
I've been thinking about adding RETURNING support to MERGE in order to
let the user see what changed.
I considered allowing a separate RETURNING list at the end of each
action, but rapidly dismissed that idea. Firstly, it introduces
shift/reduce conflicts to the grammar. These can be resolved by
On Thu, 5 Jan 2023 at 13:21, Dean Rasheed wrote:
>
> On Thu, 5 Jan 2023 at 11:03, Alvaro Herrera wrote:
> >
> > > + /* Join type required */
> > > + if (left_join && right_join)
> > > + qry->mergeJoinType = JOIN_FULL;
>
On Sat, 7 Jan 2023 at 00:36, Nathan Bossart wrote:
>
> On Fri, Jan 06, 2023 at 06:52:33PM +, Dean Rasheed wrote:
> >
> > So I think we should use the same SQL clauses as every other psql
> > command that supports "S", namely:
>
201 - 300 of 1515 matches
Mail list logo
