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
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 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
I see the PlaceHolderVar issue turned out to be a pre-existing bug after all.
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
On Wed, 8 Mar 2023 at 23:24, Thomas Munro wrote:
>
> No comment on the maths, but I'm pretty sure we won't need a fallback
> implementation. That stuff goes back to the math libraries of 80s
> Unixes, even though it didn't make it into C until '99. I just
> checked the man pages for all our
On Wed, 8 Mar 2023 at 20:11, Nathan Bossart wrote:
>
> On Mon, Feb 27, 2023 at 12:54:35PM +, Dean Rasheed wrote:
> > + /*
> > + * For erf, we don't need an errno check because it never overflows.
> > + */
>
> > + /*
> > + * For erf
On Thu, 9 Mar 2023 at 00:13, Nathan Bossart wrote:
>
> On Wed, Mar 08, 2023 at 11:29:12PM +, Dean Rasheed wrote:
> > On Wed, 8 Mar 2023 at 20:11, Nathan Bossart
> > wrote:
> >> The man pages for these seem to indicate that underflow can occur
> On Fri, 10 Mar 2023 at 21:42, Alexander Korotkov wrote:
> >
> > I wonder why does ExecMergeMatched() determine the lock mode using
> > ExecUpdateLockMode(). Why don't we use lock mode set by
> > table_tuple_update() like ExecUpdate() does? I skim through the
> > MERGE-related threads, but
On Sun, 26 Feb 2023 at 09:50, Dean Rasheed wrote:
>
> Another rebase.
>
And 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,10 +283,15
On Fri, 10 Mar 2023 at 21:42, Alexander Korotkov wrote:
>
> I wonder why does ExecMergeMatched() determine the lock mode using
> ExecUpdateLockMode(). Why don't we use lock mode set by
> table_tuple_update() like ExecUpdate() does? I skim through the
> MERGE-related threads, but didn't find an
On Tue, 21 Mar 2023 at 10:28, Alvaro Herrera wrote:
>
> > + /* Combine it with the action's WHEN condition */
> > + if (action->qual == NULL)
> > + action->qual = (Node *) ntest;
> > + else
> > +
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
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
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
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
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 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
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
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
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 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
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
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
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 20.02.23 23:16, Joel Jacobson wrote:
> > In the new attached patch, Andres fixed buffer idea has been implemented
> > throughout the entire numeric.c code base.
>
I have been going over this patch, and IMO it's far too invasive for
the fairly modest performance gains (and performance
On Tue, 28 Feb 2023 at 07:44, Peter Eisentraut
wrote:
>
> Attached is a patch to add nondecimal integer literals and underscores
> in numeric literals to the SQL JSON path language. This matches the
> recent additions to the core SQL syntax. It follows ECMAScript in
> combination with the
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
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 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
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 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 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 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 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
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
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).
>
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 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
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
On Thu, 6 Jul 2023 at 06:13, Gurjeet Singh wrote:
>
> Most of the review was done with the v6 of the patch, minus the doc
> build step. The additional changes in v7 of the patch were eyeballed,
> and tested with `make check`.
>
Thanks for the review!
> > One minor annoyance is that, due to the
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 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,
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
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 purposes of
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,
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
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
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 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 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
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
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 to
>
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)
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 Sun, 4 Feb 2024 at 18:19, zwj wrote:
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>
>This issue is related to Megre into and other concurrent statements being
> written.
>I obtained different results in Oracle and PG
On Mon, 19 Feb 2024 at 17:48, zwj wrote:
>
> Hello,
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>This question is about 'merge into'.
>
>When two merge into statements are executed concurrently, I obtain the
> following
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> Also, if the concurrent update were an update of a key
> column that was included in the join condition, the re-scan would
> follow the update to a new matching source row, which is inconsistent
> with what would happen if
On Tue, 20 Feb 2024 at 15:16, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Looking at the script itself, the addition, subtraction,
> > multiplication and division tests at the top are probably pointless,
> > since I would expect those operations to be tested adequatel
On Mon, 19 Feb 2024 at 15:35, Tom Lane wrote:
>
> I thought I'd try to acquire some actual facts here, so I compared
> the code coverage shown by "make check" as of HEAD, versus "make
> check" after adding numeric_big to parallel_schedule. I saw the
> following lines of numeric.c as being
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> On the face of it, the simplest fix is to tweak is_simple_union_all()
> to prevent UNION ALL subquery pullup for MERGE, forcing a
> subquery-scan plan. A quick test shows that that fixes the reported
> issue.
>
>
> > On 19 Feb 2024, at 12:48, Tom Lane wrote:
> >
> > Or we could just flush it. It's never detected a bug, and I think
> > you'd find that it adds zero code coverage (or if not, we could
> > fix that in a far more surgical and less expensive manner).
>
Off the top of my head, I can't say to
:00 2001
From: Dean Rasheed
Date: Fri, 25 Aug 2023 10:42:38 +0100
Subject: [PATCH v1] Add random-number-in-range functions.
This adds 3 functions:
random(min int, max int) returns int
random(min bigint, max bigint) returns bigint
random(min numeric, max numeric) returns numeric
On Thu, 7 Dec 2023 at 01:10, Joe Conway wrote:
>
> The attached should fix the CopyOut response to say one column.
>
Playing around with this, I found a couple of cases that generate an error:
COPY (SELECT 1 UNION ALL SELECT 2) TO stdout WITH (format json);
COPY (VALUES (1), (2)) TO stdout
On Mon, 18 Dec 2023 at 16:34, Jelte Fennema-Nio wrote:
>
> On Mon, 18 Dec 2023 at 16:38, Christoph Berg wrote:
> > We'd want both patches even if they do the same thing on two different
> > levels, I'd say.
>
> Makes sense.
>
I can see the appeal in this feature. However, as it stands, this
[cc'ing Joe]
On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
>
> Getting it print numeric/boolean without quotes was actually easy, as
> well as json(b). Implemented as the attached v2 patch.
>
> But: not quoting json means that NULL and 'null'::json will both be
> rendered as 'null'. That
On Tue, 9 Jan 2024 at 09:43, Christoph Berg wrote:
>
> I can see we probably wouldn't want two different output formats named
> json, but the general idea of "allow psql to format results as json of
> strings" makes a lot of sense, so we should try to make it work. Does
> it even have to be
On Mon, 14 Aug 2023 at 18:34, David Zhang wrote:
>
> it would be great to switch the order of the 3rd and the 4th line to make a
> better match for "CREATE" and "CREATE OR REPLACE" .
>
I took a look at this, and I think it's probably neater to keep the
"AS SELECT" completion for CREATE [OR
On Tue, 28 Nov 2023 at 03:42, Shubham Khanna
wrote:
>
> I reviewed the given Patch and it is working fine.
>
Thanks for checking. Patch pushed.
Regards,
Dean
I have been playing around with the idea of adding support for OLD/NEW
to RETURNING, partly motivated by the discussion on the MERGE
RETURNING thread [1], but also because I think it would be a very
useful addition for other commands (UPDATE in particular).
This was discussed a long time ago [2],
On Thu, 28 Dec 2023 at 07:34, jian he wrote:
>
> Your patch works.
> performance is the best amount for other options in [0].
> I don't have deep knowledge about which one is more random.
>
Thanks for testing.
> Currently we have to explicitly mention the lower and upper bound.
> but can we do
gly, the cfbot didn't pick up on the fact that it needed
rebasing. Anyway, the copyright years in the new file's header comment
needed updating, so here is a rebase doing that.
Regards,
Dean
From 15d0ba981ff03eca7143726fe7512adf00ee3a84 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Fri, 25 Au
n Fri, 26 Jan 2024 at 14:59, vignesh C wrote:
>
> CFBot shows that the patch does not apply anymore as in [1]:
>
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index f8f83d4..6ef0c2b
--- a/doc/src/sgml/mvcc.sgml
+++
On Mon, 22 Jan 2024 at 02:10, Peter Smith wrote:
>
> Hi, this patch was marked in CF as "Needs Review" [1], but there has
> been no activity on this thread for 6+ months.
>
> Is anything else planned? Can you post something to elicit more
> interest in the latest patch? Otherwise, if nothing
On Tue, 30 Jan 2024 at 12:47, Aleksander Alekseev
wrote:
>
> Maybe I'm missing something but I'm not sure if I understand what this
> test tests particularly:
>
> ```
> -- There should be no triple duplicates in 1000 full-range 32-bit random()
> -- values. (Each of the C(1000, 3) choices of
On Fri, 26 Jan 2024 at 15:57, Alvaro Herrera wrote:
>
> Well, firstly this is clearly a feature we want to have, even though
> it's non-standard, because people use it and other implementations have
> it. (Eh, so maybe somebody should be talking to the SQL standard
> committee about it). As for
On Mon, 13 Nov 2023 at 05:29, jian he wrote:
>
> v13 works fine. all tests passed. The code is very intuitive. played
> with multi WHEN clauses, even with before/after row triggers, work as
> expected.
>
Thanks for the review and testing!
> I don't know when replace_outer_merging will be
On Fri, 17 Nov 2023 at 04:30, jian he wrote:
>
> I think it should be:
> + You will require the SELECT privilege on any column(s)
> + of the data_source and
> + target_table_name referred to
> + in any condition or expression.
>
Ah, of course. As always, I'm blind to grammatical errors
On Thu, 9 Nov 2023 at 12:49, Dean Rasheed wrote:
>
> OK, I have pushed 0001 and 0002. Here's the remaining (main) patch.
>
OK, I have now pushed the main patch.
Regards,
Dean
One of the new tests in the infinite interval patch has revealed a bug
in our 64-bit integer subtraction code. Consider the following:
select 0::int8 - '-9223372036854775808'::int8;
This should overflow, since the correct result (+9223372036854775808)
is out of range. However, on platforms
On Wed, 8 Nov 2023 at 06:56, jian he wrote:
>
> > On Tue, 7 Nov 2023 at 14:33, Dean Rasheed wrote:
> >
> > Ah, Windows Server didn't like that. Trying again with "INT64CONST(0)"
> > instead of just "0" in interval_um().
> >
> I found this
On Thu, 9 Nov 2023 at 15:16, Laurenz Albe wrote:
>
> I have thought some more about this, and I believe that if FOR SELECT
> policies are used to check new rows, you should be allowed to specify
> WITH CHECK on FOR SELECT policies. Why not allow a user to specify
> different conditions for
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, 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
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
On Mon, 1 Jan 2024 at 13:28, Ayush Vatsa wrote:
>
> According to the documentation of pg_dump when the --extension option is not
> specified, all non-system extensions in the target database will get dumped.
> > Why do we need to explicitly exclude extensions?
> Hence to include only a few we
On Wed, 6 Mar 2024 at 08:51, Peter Eisentraut wrote:
>
> For comparison with standard SQL (see ):
>
> For an INSERT you could write
>
> SELECT whatever FROM NEW TABLE (INSERT statement here)
>
> or for an DELETE
>
> SELECT whatever FROM OLD TABLE (DELETE statement here)
>
> And for an UPDATE
On Thu, 7 Mar 2024 at 17:32, Alvaro Herrera wrote:
>
> This seems to work okay.
>
Yes, this looks good. I tested it against CREATE TABLE ... LIKE, and
it worked as expected. It might be worth adding a test case for that,
to ensure that it doesn't get broken in the future. Do we also want a
test
On Wed, 6 Mar 2024 at 22:22, Nathan Bossart wrote:
>
> Thanks for taking a look. I updated the synopsis sections in v3.
OK, that looks good. The vacuumdb synopsis in particular looks a lot
better now that "-N | --exclude-schema" is on its own line, because it
was hard to read previously, and
On Fri, 16 Feb 2024 at 19:39, Tom Lane wrote:
>
> > So now I'm thinking that we do have enough detail in the present
> > proposal, and we just need to think about whether there's some
> > nicer way to present it than the particular spelling I used here.
>
One thing that concerns me about making
On Fri, 15 Mar 2024 at 17:14, Jeff Davis wrote:
>
> On Fri, 2024-03-15 at 11:20 +, Dean Rasheed wrote:
>
> > So barring any further objections, I'd like to go ahead and get this
> > patch committed.
>
> I like this feature from a user perspective. So +1 f
On Fri, 15 Mar 2024 at 11:06, Dean Rasheed wrote:
>
> Updated patch attached.
>
I have gone over this patch again in detail, and I believe that the
code is in good shape. All review comments have been addressed, and
the only thing remaining is the syntax question.
To recap, this add
On Sun, 17 Mar 2024 at 19:39, Tom Lane wrote:
>
> Here's a cleaned-up version that seems to successfully resolve
> PARAM_EXEC references in all cases. I haven't changed the
> "(plan_name).colN" notation, but that's an easy fix once we have
> consensus on the spelling.
I took a more detailed
On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>
> > Hm. I used "rescan(SubPlan)" in the attached, but it still looks
> > a bit odd to my eye.
>
> After thinking a bit more, I understood what was bothering me about
> that notation: it looks too much like a call of a user-defined
> function named
On Sat, 16 Mar 2024 at 17:36, Ayush Vatsa wrote:
>
> Attached is the complete patch with all the required code changes.
> Looking forward to your review and feedback.
>
This looks good to me. I tested it and everything worked as expected.
I ran it through pgindent to fix some whitespace issues
On Wed, 13 Mar 2024 at 06:44, jian he wrote:
>
>
> [ WITH with_query [, ...] ]
> MERGE INTO [ ONLY ]
> here the "WITH" part should have "[ RECURSIVE ]"
Actually, no. MERGE doesn't support WITH RECURSIVE.
It's not entirely clear to me why though. I did a quick test, removing
that restriction
On Wed, 13 Mar 2024 at 08:58, Dean Rasheed wrote:
>
> I think I'll go make those doc changes, and back-patch them
> separately, since they're not related to this patch.
>
OK, I've done that. Here is a rebased patch on top of that, with the
other changes you suggested.
Regards,
Dea
401 - 500 of 532 matches
Mail list logo
