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 Thu, 18 Apr 2024 at 13:00, Aleksander Alekseev
wrote:
>
> Fair point. PFA the alternative version of the patch.
>
Thanks. Committed.
Regards,
Dean
Use macro NUM_MERGE_MATCH_KINDS instead of '3' in MERGE code.
Code quality improvement for 0294df2f1f84.
Aleksander Alekseev, reviewed by Richard Guo.
Discussion:
https://postgr.es/m/CAJ7c6TMsiaV5urU_Pq6zJ2tXPDwk69-NKVh4AMN5XrRiM7N%2BGA%40mail.gmail.com
Branch
--
master
Details
---
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
or BY TARGET is
equivalent to writing WHEN NOT MATCHED BY TARGET.
Dean Rasheed, reviewed by Alvaro Herrera, Ted Yu and Vik Fearing.
Discussion:
https://postgr.es/m/CAEZATCWqnKGc57Y_JanUBHQXNKcXd7r=0r4nezuvwp+syrk...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg
On Wed, 27 Mar 2024 at 07:47, Jeff Davis wrote:
>
> This isn't a complete review, but I spent a while looking at this, and
> it looks like it's in good shape.
Thanks for looking.
> I like the syntax, and I think the solution for renaming the alias
> ("RETURNING WITH (new as n, old as o)") is a
On Tue, 26 Mar 2024 at 06:57, Dean Rasheed wrote:
>
> Based on the reviews so far, I think this is ready for commit, so
> unless anyone objects, I will do so in a day or so.
>
Committed. Thanks for the reviews.
Regards,
Dean
file.
The existing random(), random_normal(), and setseed() functions are
moved there too, so that they can all share the same PRNG state, which
is kept private to that file.
Dean Rasheed, reviewed by Jian He, David Zhang, Aleksander Alekseev,
and Tomas Vondra.
Discussion:
https://postgr.es
On Tue, 26 Mar 2024 at 07:30, Alvaro Herrera wrote:
>
> On 2024-Mar-25, Dean Rasheed wrote:
>
> > Also (not this patch's fault), psql doesn't seem to offer a way to
> > display domain constraint names -- something you need to know to drop
> > or alter them. Perha
On Thu, 21 Mar 2024 at 09:35, Dean Rasheed wrote:
>
> Trivial rebase forced by 6185c9737c.
>
I think it would be good to get this committed.
It has had a decent amount of review, at least up to v9, but a number
of things have changed since then:
1). Concurrent update behavio
On Tue, 27 Feb 2024 at 17:33, Dean Rasheed wrote:
>
> On Sat, 24 Feb 2024 at 17:10, Tomas Vondra
> >
> > I did a quick review and a little bit of testing on the patch today. I
> > think it's a good/useful idea, and I think the code is ready to go (the
> > code
On Fri, 22 Mar 2024 at 08:28, jian he wrote:
>
> On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut wrote:
> >
> > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > table constraint syntax. Attached is a patch to try to sort this out.
>
> also you should also change
On Wed, 20 Mar 2024 at 09:43, Peter Eisentraut wrote:
>
> On 19.03.24 10:57, jian he wrote:
> > this new syntax need to be added into the alter_domain.sgml's synopsis and
> > also
> > need an explanation varlistentry?
>
> The ALTER DOMAIN reference page refers to CREATE DOMAIN about the
>
On Tue, 19 Mar 2024 at 19:17, Ayush Vatsa wrote:
>
> > I'm marking this ready-for-commit (which I'll probably do myself in a
> > day or two, unless anyone else claims it first).
>
> Thank you very much, this marks my first contribution to the open-source
> community, and I'm enthusiastic about
Add "--exclude-extension" to pg_dump's options.
This option (or equivalently specifying "exclude extension pattern" in
a filter file) allows extensions matching the specified pattern to be
excluded from the dump.
Ayush Vatsa, reviewed by Junwang Zhao, Dean Rasheed, a
On Tue, 19 Mar 2024 at 21:40, Tom Lane wrote:
>
> I'm inclined to leave that alone. The actual source sub-SELECT
> could only have had one column, so no real confusion is possible.
> Yeah, there's a resjunk grouping column visible in the plan as well,
> but those exist in many other queries, and
On Tue, 19 Mar 2024 at 16:42, Tom Lane wrote:
>
> Here's a hopefully-final version that makes that adjustment and
> tweaks a couple of comments.
>
This looks very good to me.
One final case that could possibly be improved is this one from aggregates.out:
explain (verbose, costs off)
select
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 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 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 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
Fix PDF doc generation.
Commit c649fa24a4 broke PDF generation, due to a misplaced id
attribute.
Per buildfarm member crake.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7eb9a8201890f3b208fd4c109a5b08bf139b692a
Modified Files
--
of a MERGE
query's RETURNING list.
Dean Rasheed, reviewed by Isaac Morland, Vik Fearing, Alvaro Herrera,
Gurjeet Singh, Jian He, Jeff Davis, Merlin Moncure, Peter Eisentraut,
and Wolfgang Walther.
Discussion:
http://postgr.es/m/CAEZATCWePEGQR5LBn-vD6SfeLZafzEm2Qy_L_Oky2=qw2w3...@mail.gmail.com
Fix EXPLAIN output for subplans in MERGE.
Given a subplan in a MERGE query, EXPLAIN would sometimes fail to
properly display expressions involving Params referencing variables in
other parts of the plan tree.
This would affect subplans outside the topmost join plan node, for
which expansion of
Fix EXPLAIN output for subplans in MERGE.
Given a subplan in a MERGE query, EXPLAIN would sometimes fail to
properly display expressions involving Params referencing variables in
other parts of the plan tree.
This would affect subplans outside the topmost join plan node, for
which expansion of
Fix EXPLAIN output for subplans in MERGE.
Given a subplan in a MERGE query, EXPLAIN would sometimes fail to
properly display expressions involving Params referencing variables in
other parts of the plan tree.
This would affect subplans outside the topmost join plan node, for
which expansion of
On Sat, 16 Mar 2024 at 17:25, Tom Lane wrote:
>
> After looking at your draft some more, it occurred to me that we're
> not that far from getting rid of showing "$n" entirely in this
> context. Instead of (subplan_name).$n, we could write something like
> (subplan_name).colN or
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
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..380d0c9
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -394,10 +394,14 @@
conditions for each action are re-evaluated on the updated version
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
doc: Improve a couple of places in the MERGE docs.
In the synopsis, make the syntax for merge_update consistent with the
syntax for a plain UPDATE command. It was missing the optional "ROW"
keyword that can be used in a multi-column assignment, and the option
to assign from a multi-column
doc: Improve a couple of places in the MERGE docs.
In the synopsis, make the syntax for merge_update consistent with the
syntax for a plain UPDATE command. It was missing the optional "ROW"
keyword that can be used in a multi-column assignment, and the option
to assign from a multi-column
doc: Improve a couple of places in the MERGE docs.
In the synopsis, make the syntax for merge_update consistent with the
syntax for a plain UPDATE command. It was missing the optional "ROW"
keyword that can be used in a multi-column assignment, and the option
to assign from a multi-column
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
While playing around with EXPLAIN and SubPlans, I noticed that there's
a bug in how this is handled for MERGE. For example:
drop table if exists src, tgt, ref;
create table src (a int, b text);
create table tgt (a int, b text);
create table ref (a int);
explain (verbose, costs off)
merge into
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 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 Thu, 7 Mar 2024 at 13:00, Alvaro Herrera wrote:
>
> So I think the original developers of REPLICA IDENTITY had the right
> idea here (commit 07cacba983ef), and we mustn't change this aspect,
> because it'll lead to data corruption in replication. Using a deferred
> PK for DDL considerations
On Tue, 5 Mar 2024 at 13:55, Dean Rasheed wrote:
>
> > If I only execute merge , I will get the following error:
> > merge into tgt a using src1 c on a.a = c.a when matched then update
> > set b = c.b when not matched then insert (a,b) values(c.a,c.b); -- excute
&
Fix handling of self-modified tuples in MERGE.
When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:
1). The target tuple was already updated or deleted by the current
command. This can happen if the target row joins to more than one
source row,
Fix handling of self-modified tuples in MERGE.
When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:
1). The target tuple was already updated or deleted by the current
command. This can happen if the target row joins to more than one
source row,
Fix handling of self-modified tuples in MERGE.
When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:
1). The target tuple was already updated or deleted by the current
command. This can happen if the target row joins to more than one
source row,
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 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 Tue, 5 Mar 2024 at 02:22, Nathan Bossart wrote:
>
> I saw that this thread was referenced elsewhere [0], so I figured I'd take
> a fresh look. From a quick glance, I'd say 0001 and 0002 are pretty
> reasonable and could probably be committed for v17.
>
I'm not sure how useful these changes
On Tue, 5 Mar 2024 at 12:36, Alvaro Herrera wrote:
>
> Yeah. As I said upthread, a good fix seems to require no longer relying
> on RelationGetIndexAttrBitmap to obtain the columns in the primary key,
> because that function does not include deferred primary keys. I came up
> with the attached
[cc'ing Alvaro]
On Tue, 5 Mar 2024 at 10:04, zwj wrote:
>
> If I only execute merge , I will get the following error:
> merge into tgt a using src1 c on a.a = c.a when matched then update set
> b = c.b when not matched then insert (a,b) values(c.a,c.b); -- excute fail
> ERROR: MERGE
On Mon, 4 Mar 2024 at 12:34, Aleksander Alekseev
wrote:
>
> > This was an experimental patch, I was looking for the comment on the
> > proposed
> > approach -- whether we could simply skip the throwaway NOT NULL constraint
> > for
> > deferred PK constraint. Moreover, skip that for any PK
Fix doc omission for MERGE into updatable views.
Commit 5f2e179bd3 missed one place in rules.sgml that should have
mentioned MERGE. Also, be more specific when saying that MERGE doesn't
support rules, since it does support SELECT rules.
Branch
--
master
Details
---
On Thu, 29 Feb 2024 at 09:50, Alvaro Herrera wrote:
>
> By all means let's get the feature out there. It's not a frequently
> requested thing but it does seem to come up.
>
Pushed. Thanks for reviewing.
Regards,
Dean
there is no
rewriter support for non-SELECT rules with MERGE operations.
Dean Rasheed, reviewed by Jian He and Alvaro Herrera.
Discussion:
https://postgr.es/m/CAEZATCVcB1g0nmxuEc-A+gGB0HnfcGQNGYH7gS=7rq0u0zo...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg
ate(),
ensuring that ExecUpdateEpilogue() is always called if ExecUpdateAct()
returns TM_Ok, reducing the chance of bugs.
Dean Rasheed, reviewed by Alvaro Herrera.
Discussion:
https://postgr.es/m/CAEZATCWGGmigGBzLHkJm5Ccv2mMxXmwi3%2Buq0yhwDHm-tsvSLg%40mail.gmail.com
Branch
--
master
Deta
On Wed, 28 Feb 2024 at 09:16, jian he wrote:
>
> + oldcontext = MemoryContextSwitchTo(estate->es_query_cxt);
> +
> + node->as_epq_tupdesc = lookup_rowtype_tupdesc_copy(tupType, tupTypmod);
> +
> + ExecAssignExprContext(estate, >ps);
> +
> + node->ps.ps_ProjInfo =
> +
efault distribution, if omitted.
For different result datatypes, it ought to be mostly possible to
determine the result type from the arguments. There might be some
exceptions, like maybe "random_bytes(length)" to generate a byte
array, but I think that would be OK.
Regards,
Dean
From b1
On Fri, 23 Feb 2024 at 00:12, Tom Lane wrote:
>
> So after studying this for awhile, I see that the planner is emitting
> a PlanRowMark that presumes that the UNION ALL subquery will be
> scanned as though it's a base relation; but since we've converted it
> to an appendrel, the executor just
On Fri, 23 Feb 2024 at 14:35, Peter Eisentraut wrote:
>
> Various code comments say that the RangeTblEntry field inh may only be
> set for entries of kind RTE_RELATION.
>
> The function pull_up_simple_union_all() in prepjointree.c sets ->inh to
> true for RTE_SUBQUERY entries:
>
> /*
>
On Thu, 22 Feb 2024 at 03:46, zwj wrote:
>
> If I want to get the same results as Oracle, do I need to adjust the lock
> behavior of the update and merge statements?
> If I want to achieve the same results as Oracle, can I achieve exclusive
> locking by adjusting update and merge? Do you
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 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 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 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 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 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
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 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
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
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
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
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
[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 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
: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
, so that it updates the command tag if it does a
cross-partition update, making this code path in ExecMergeMatched()
consistent with ExecUpdate().
Per bug #18238 from Alexander Lakhin. Back-patch to v15, where MERGE
was introduced.
Dean Rasheed, reviewed by Richard Guo and Jian He.
Discussion
, so that it updates the command tag if it does a
cross-partition update, making this code path in ExecMergeMatched()
consistent with ExecUpdate().
Per bug #18238 from Alexander Lakhin. Back-patch to v15, where MERGE
was introduced.
Dean Rasheed, reviewed by Richard Guo and Jian He.
Discussion
, so that it updates the command tag if it does a
cross-partition update, making this code path in ExecMergeMatched()
consistent with ExecUpdate().
Per bug #18238 from Alexander Lakhin. Back-patch to v15, where MERGE
was introduced.
Dean Rasheed, reviewed by Richard Guo and Jian He.
Discussion
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 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
psql: Add tab completion for view options.
Add support for tab completion of WITH (...) options to CREATE VIEW,
and for the corresponding SET/RESET (...) options in ALTER VIEW.
Christoph Heiss, reviewed by Melih Mutlu, Vignesh C, Jim Jones,
Mikhail Gribkov, David Zhang, Shubham Khanna, and me.
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
Guard against overflow in interval_mul() and interval_div().
Commits 146604ec43 and a898b409f6 added overflow checks to
interval_mul(), but not to interval_div(), which contains almost
identical code, and so is susceptible to the same kinds of
overflows. In addition, those checks did not catch
Guard against overflow in interval_mul() and interval_div().
Commits 146604ec43 and a898b409f6 added overflow checks to
interval_mul(), but not to interval_div(), which contains almost
identical code, and so is susceptible to the same kinds of
overflows. In addition, those checks did not catch
Guard against overflow in interval_mul() and interval_div().
Commits 146604ec43 and a898b409f6 added overflow checks to
interval_mul(), but not to interval_div(), which contains almost
identical code, and so is susceptible to the same kinds of
overflows. In addition, those checks did not catch
Guard against overflow in interval_mul() and interval_div().
Commits 146604ec43 and a898b409f6 added overflow checks to
interval_mul(), but not to interval_div(), which contains almost
identical code, and so is susceptible to the same kinds of
overflows. In addition, those checks did not catch
Guard against overflow in interval_mul() and interval_div().
Commits 146604ec43 and a898b409f6 added overflow checks to
interval_mul(), but not to interval_div(), which contains almost
identical code, and so is susceptible to the same kinds of
overflows. In addition, those checks did not catch
Guard against overflow in interval_mul() and interval_div().
Commits 146604ec43 and a898b409f6 added overflow checks to
interval_mul(), but not to interval_div(), which contains almost
identical code, and so is susceptible to the same kinds of
overflows. In addition, those checks did not catch
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
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
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
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
1 - 100 of 1507 matches
Mail list logo
