doc: improve description of privileges for MERGE and update glossary.
On the MERGE page, the description of the privileges required could be
taken to imply that the SELECT privilege is required on all columns of
the data source, whereas actually it is only required on the columns
referred to by
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 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
Support +/- infinity in the interval data type.
This adds support for infinity to the interval data type, using the
same input/output representation as the other date/time data types
that support infinity. This allows various arithmetic operations on
infinite dates, timestamps and intervals.
The
On Thu, 9 Nov 2023 at 18:55, Laurenz Albe wrote:
>
> I think it can be useful to allow a user an UPDATE where the result
> does not satisfy the USING clause of the FOR SELECT policy.
>
> The idea that an UPDATE should only produce rows you can SELECT is not
> true today: if you run an UPDATE
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 Sun, 5 Nov 2023 at 11:52, Dean Rasheed wrote:
>
> OK, that's a fair point. Attached is a new version, replacing those
> parts of the implementation with a new MergingFunc node. It doesn't
> add that much more complexity, and I think the new code is much
> neater.
>
Rebase
Avoid integer overflow hazard in interval_time().
When casting an interval to a time, the original code suffered from
64-bit integer overflow for inputs with a sufficiently large negative
"time" field, leading to bogus results.
Fix by rewriting the algorithm in a simpler form, that more
Fix AFTER ROW trigger execution in MERGE cross-partition update.
When executing a MERGE UPDATE action, if the UPDATE is turned into a
cross-partition DELETE then INSERT, do not attempt to invoke AFTER
UPDATE ROW triggers, or any of the other post-update actions in
ExecUpdateEpilogue().
For
Fix AFTER ROW trigger execution in MERGE cross-partition update.
When executing a MERGE UPDATE action, if the UPDATE is turned into a
cross-partition DELETE then INSERT, do not attempt to invoke AFTER
UPDATE ROW triggers, or any of the other post-update actions in
ExecUpdateEpilogue().
For
Fix AFTER ROW trigger execution in MERGE cross-partition update.
When executing a MERGE UPDATE action, if the UPDATE is turned into a
cross-partition DELETE then INSERT, do not attempt to invoke AFTER
UPDATE ROW triggers, or any of the other post-update actions in
ExecUpdateEpilogue().
For
Fix corner-case 64-bit integer subtraction bug on some platforms.
When computing "0 - INT64_MIN", most platforms would report an
overflow error, which is correct. However, platforms without integer
overflow builtins or 128-bit integers would fail to spot the overflow,
and incorrectly return
Fix corner-case 64-bit integer subtraction bug on some platforms.
When computing "0 - INT64_MIN", most platforms would report an
overflow error, which is correct. However, platforms without integer
overflow builtins or 128-bit integers would fail to spot the overflow,
and incorrectly return
Fix corner-case 64-bit integer subtraction bug on some platforms.
When computing "0 - INT64_MIN", most platforms would report an
overflow error, which is correct. However, platforms without integer
overflow builtins or 128-bit integers would fail to spot the overflow,
and incorrectly return
Fix corner-case 64-bit integer subtraction bug on some platforms.
When computing "0 - INT64_MIN", most platforms would report an
overflow error, which is correct. However, platforms without integer
overflow builtins or 128-bit integers would fail to spot the overflow,
and incorrectly return
Fix corner-case 64-bit integer subtraction bug on some platforms.
When computing "0 - INT64_MIN", most platforms would report an
overflow error, which is correct. However, platforms without integer
overflow builtins or 128-bit integers would fail to spot the overflow,
and incorrectly return
Fix corner-case 64-bit integer subtraction bug on some platforms.
When computing "0 - INT64_MIN", most platforms would report an
overflow error, which is correct. However, platforms without integer
overflow builtins or 128-bit integers would fail to spot the overflow,
and incorrectly return
On Thu, 9 Nov 2023 at 07:15, Ashutosh Bapat
wrote:
>
> Just to test whether that bug fix also fixes the failure seen with
> this patchset, I am attaching the patchset including the patch with
> the fix.
>
> 0001 - fix in other thread
> 0002 and 0003 are 0001 and 0002 in the previous patch set.
>
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
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
While working on the MERGE RETURNING patch, I noticed a pre-existing
MERGE bug --- ExecMergeMatched() should not call ExecUpdateEpilogue()
if ExecUpdateAct() indicates that it did a cross-partition update.
The immediate consequence is that it incorrectly tries (and fails) to
fire AFTER UPDATE ROW
On Wed, 1 Nov 2023 at 17:49, Jeff Davis wrote:
>
> Most of my concern is that parts of the implementation feel like a
> hack, which makes me concerned that we're approaching it the wrong way.
>
OK, that's a fair point. Attached is a new version, replacing those
parts of the implementation with a
On Tue, 31 Oct 2023 at 23:19, Vik Fearing wrote:
>
> On 10/31/23 19:28, Jeff Davis wrote:
>
> > Assuming we have one RETURNING clause at the end, then it creates the
> > problem of how to communicate which WHEN clause a tuple came from,
> > whether it's the old or the new version, and/or which
On Sat, 28 Oct 2023 at 09:35, jian he wrote:
>
> hi.
> Excellent work! regress test passed! The code looks so intuitive!
>
Thanks for looking!
> doc/src/sgml/ref/create_view.sgml.
> Do we need to add
> If the view or any of its base
> relations has an
Guard against overflow in make_interval().
The original code did very little to guard against integer or floating
point overflow when computing the interval's fields. Detect any such
overflows and error out, rather than silently returning bogus results.
Joseph Koshakow, reviewed by Ashutosh
terval values.
Fix by setting all fields of the leftmost interval to their minimum
values, ensuring that the result is less than any other possible
interval. Since this only affects index searches, no index rebuild is
necessary.
Back-patch to all supported branches.
Dean Rasheed, reviewed by
terval values.
Fix by setting all fields of the leftmost interval to their minimum
values, ensuring that the result is less than any other possible
interval. Since this only affects index searches, no index rebuild is
necessary.
Back-patch to all supported branches.
Dean Rasheed, reviewed by
terval values.
Fix by setting all fields of the leftmost interval to their minimum
values, ensuring that the result is less than any other possible
interval. Since this only affects index searches, no index rebuild is
necessary.
Back-patch to all supported branches.
Dean Rasheed, reviewed by
terval values.
Fix by setting all fields of the leftmost interval to their minimum
values, ensuring that the result is less than any other possible
interval. Since this only affects index searches, no index rebuild is
necessary.
Back-patch to all supported branches.
Dean Rasheed, reviewed by
terval values.
Fix by setting all fields of the leftmost interval to their minimum
values, ensuring that the result is less than any other possible
interval. Since this only affects index searches, no index rebuild is
necessary.
Back-patch to all supported branches.
Dean Rasheed, reviewed by
terval values.
Fix by setting all fields of the leftmost interval to their minimum
values, ensuring that the result is less than any other possible
interval. Since this only affects index searches, no index rebuild is
necessary.
Back-patch to all supported branches.
Dean Rasheed, reviewed by
terval values.
Fix by setting all fields of the leftmost interval to their minimum
values, ensuring that the result is less than any other possible
interval. Since this only affects index searches, no index rebuild is
necessary.
Back-patch to all supported branches.
Dean Rasheed, reviewed by
On Wed, 25 Oct 2023 at 02:07, Merlin Moncure wrote:
>
> On Tue, Oct 24, 2023 at 2:11 PM Jeff Davis wrote:
>>
>> Can we revisit the idea of a per-WHEN RETURNING clause? The returning
>> clauses could be treated kind of like a UNION, which makes sense
>> because it really is a union of different
On Fri, 27 Oct 2023 at 13:56, Ashutosh Bapat
wrote:
>
> Should we change this to call INTERVAL_NOBEGIN() to be added by
> infinite interval patches?
>
Given that this is a bug that can lead to incorrect query results, I
plan to back-patch it, and INTERVAL_NOBEGIN() wouldn't make sense in
In contrib/btree_gin, leftmostvalue_interval() does this:
leftmostvalue_interval(void)
{
Interval *v = palloc(sizeof(Interval));
v->time = DT_NOBEGIN;
v->day = 0;
v->month = 0;
return IntervalPGetDatum(v);
}
which is a long way short of the minimum possible interval value.
On Wed, 4 Oct 2023 at 14:29, Ashutosh Bapat
wrote:
>
> I think we should introduce interval_out_of_range_error() function on
> the lines of float_overflow_error(). Later patches introduce more
> places where we raise that error. We can introduce the function as
> part of those patches.
>
I'm not
On Tue, 24 Oct 2023 at 09:36, Laurenz Albe wrote:
>
> I'd say that this error is wrong. The FOR SELECT policy should be applied
> to the WHERE condition, but certainly not to check new rows.
>
Yes, I had the same thought recently. I would say that the SELECT
policies should only be used to
On Thu, 19 Oct 2023, 05:32 Ashutosh Bapat,
wrote:
> On Wed, Oct 18, 2023 at 8:23 PM Tomas Vondra
> wrote:
>
> >
> > I did use that many values to actually force "compaction" and merging of
> > points into ranges. We only keep 32 values per page range, so with 2
> > values we'll not build a
On Wed, 18 Oct 2023 at 09:16, Tomas Vondra
wrote:
>
> BTW when adding the tests with extreme values, I noticed this:
>
> test=# select '5874897-01-01'::date;
>date
> ---
>5874897-01-01
> (1 row)
>
> test=# select '5874897-01-01'::date + '1 second'::interval;
>
On Tue, 17 Oct 2023 at 21:25, Tomas Vondra
wrote:
>
> Here's a couple cleaned-up patches fixing the various discussed here.
> I've tried to always add a regression test demonstrating the issue
> first, and then fix it in the next patch.
>
This looks good to me.
> 2) incorrect subtraction in
On Fri, 13 Oct 2023 at 13:17, Tomas Vondra
wrote:
>
> I do plan to backpatch this, yes. I don't think there are many people
> affected by this (few people are using infinite dates/timestamps, but
> maybe the overflow could be more common).
>
OK, though I doubt that such values are common in
On Fri, 13 Oct 2023 at 11:44, Tomas Vondra
wrote:
>
> On 10/13/23 11:21, Dean Rasheed wrote:
> >
> > Is this only inefficient? Or can it also lead to wrong query results?
>
> I don't think it can produce incorrect results. It only affects which
> values we "merge
On Thu, 12 Oct 2023 at 23:43, Tomas Vondra
wrote:
>
> Ashutosh Bapat reported me off-list a possible issue in how BRIN
> minmax-multi calculate distance for infinite timestamp/date values.
>
> The current code does this:
>
> if (TIMESTAMP_NOT_FINITE(dt1) || TIMESTAMP_NOT_FINITE(dt2))
>
On Mon, 2 Oct 2023 at 01:01, Tom Lane wrote:
>
> Erwin Brandstetter writes:
> > On Mon, 2 Oct 2023 at 00:33, Dean Rasheed wrote:
> >> The only place that exposes the eref's made-up relation name is the
> >> existing query deparsing code in ruleutils.c, which uniqui
to return the same source
tuples when re-running the join query.
Fix by ensuring that preprocess_rowmarks() sets up PlanRowMarks for
all non-target relations used in MERGE, in the same way that it does
for UPDATE and DELETE.
Per bug #18103. Back-patch to v15, where MERGE was introduced.
Dean Rasheed
to return the same source
tuples when re-running the join query.
Fix by ensuring that preprocess_rowmarks() sets up PlanRowMarks for
all non-target relations used in MERGE, in the same way that it does
for UPDATE and DELETE.
Per bug #18103. Back-patch to v15, where MERGE was introduced.
Dean Rasheed
to return the same source
tuples when re-running the join query.
Fix by ensuring that preprocess_rowmarks() sets up PlanRowMarks for
all non-target relations used in MERGE, in the same way that it does
for UPDATE and DELETE.
Per bug #18103. Back-patch to v15, where MERGE was introduced.
Dean Rasheed
On Fri, 22 Sept 2023 at 08:49, Ashutosh Bapat
wrote:
>
> Following code in ExecInterpExpr makes it clear that the
> deserialization function is be executed in per tuple memory context.
> Whereas the aggregate's context is different from this context and may
> lives longer that the context in
On Wed, 20 Sept 2023 at 15:00, Ashutosh Bapat
wrote:
>
> 0005 - Refactored Jian's code fixing window functions. Does not
> contain the changes for serialization and deserialization. Jian,
> please let me know if I have missed anything else.
>
That looks a lot neater. One thing I don't care for
On Wed, 20 Sept 2023 at 13:09, Dean Rasheed wrote:
>
> So basically, do_interval_accum() could be simplified to:
>
Oh, and I guess it also needs an INTERVAL_NOT_FINITE() check, to make
sure that finite values don't sum to our representation of infinity,
as in interval_pl().
Regards,
Dean
On Wed, 20 Sept 2023 at 11:27, jian he wrote:
>
> if I remove IntervalAggState's element: MemoryContext, it will not work.
> so I don't understand what the above sentence means.. Sorry. (it's
> my problem)
>
I don't see why it won't work. The point is to try to simplify
do_interval_accum()
On Sat, 16 Sept 2023 at 01:00, jian he wrote:
>
> I refactor the avg(interval), sum(interval), so moving aggregate,
> plain aggregate both work with +inf/-inf.
> no performance degradation, in fact, some performance gains.
>
I haven't reviewed this part in any detail yet, but I can confirm that
On Fri, 15 Sept 2023 at 08:00, vignesh C wrote:
>
> On Thu, 14 Sept 2023 at 15:33, Himanshu Upadhyaya
> wrote:
> >
> > On Thu, Sep 14, 2023 at 9:57 AM vignesh C wrote:
> >>
> >> postgres=*# SET CONSTRAINTS tbl_chk_1 DEFERRED;
> >> SET CONSTRAINTS
> >> postgres=*# INSERT INTO tbl values (1);
>
On Wed, 13 Sept 2023 at 11:13, Ashutosh Bapat
wrote:
>
> On Tue, Sep 12, 2023 at 2:39 PM Dean Rasheed wrote:
> >
> > and it looks like the infinite interval
> > input code is broken.
>
> The code required to handle 'infinity'
On Thu, 24 Aug 2023 at 14:51, Ashutosh Bapat
wrote:
>
> The patches still apply. But here's a rebased version with one white
> space error fixed. Also ran pgindent.
>
This needs another rebase, and it looks like the infinite interval
input code is broken.
I took a quick look, and had a couple
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
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
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 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 use
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
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,
policies to the join).
Back-patch to v15, where MERGE was introduced.
Dean Rasheed, reviewed by Stephen Frost.
Security: CVE-2023-39418
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/cb2ae5741f2458a474ed3c31458d242e678ff229
Modified Files
policies to the join).
Back-patch to v15, where MERGE was introduced.
Dean Rasheed, reviewed by Stephen Frost.
Security: CVE-2023-39418
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c2e08b04c9e71ac6aabdc7d9b3f8e785e164d770
Modified Files
--
src
policies to the join).
Back-patch to v15, where MERGE was introduced.
Dean Rasheed, reviewed by Stephen Frost.
Security: CVE-2023-39418
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/67a007dc0cdb8578726c2000a7abc513109cb4a2
Modified Files
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 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 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 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 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, 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
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 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
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 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, 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, 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 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 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 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 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 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 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
> > +
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
implementations. However, past experience has shown that there are
almost certainly going to be additional unexpected portability issues,
so these tests may well need further adjustments, based on the
buildfarm results.
Dean Rasheed, reviewed by Nathan Bossart and Thomas Munro.
Discussion:
https
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
Fix MERGE command tag for actions blocked by BEFORE ROW triggers.
This ensures that the row count in the command tag for a MERGE is
correctly computed in the case where UPDATEs or DELETEs are skipped
due to a BEFORE ROW trigger returning NULL (the INSERT case was
already handled correctly by
Fix MERGE command tag for actions blocked by BEFORE ROW triggers.
This ensures that the row count in the command tag for a MERGE is
correctly computed in the case where UPDATEs or DELETEs are skipped
due to a BEFORE ROW trigger returning NULL (the INSERT case was
already handled correctly by
Fix concurrent update issues with MERGE.
If MERGE attempts an UPDATE or DELETE on a table with BEFORE ROW
triggers, or a cross-partition UPDATE (with or without triggers), and
a concurrent UPDATE or DELETE happens, the merge code would fail.
In some cases this would lead to a crash, while in
Fix concurrent update issues with MERGE.
If MERGE attempts an UPDATE or DELETE on a table with BEFORE ROW
triggers, or a cross-partition UPDATE (with or without triggers), and
a concurrent UPDATE or DELETE happens, the merge code would fail.
In some cases this would lead to a crash, while in
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 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 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 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 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
101 - 200 of 1515 matches
Mail list logo
