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 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 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 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
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
&
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
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, 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 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 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, 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
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 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, 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 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
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 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 =
> +
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
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
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 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 Wed, 15 May 2024 at 02:14, Erik Wienhold wrote:
>
> plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
>
> Fixed in the attached patch.
>
Nice catch! The patch looks good to me on a quick read-through.
I'll take a closer look next week, after the beta release, since it's
a v16+
On Thu, 16 May 2024 at 15:15, Peter Eisentraut wrote:
>
> I wonder if we can avoid making MERGE_ACTION a keyword.
>
Yeah, there was a lot of back and forth on this point on the original
thread, and I'm still not sure which approach is best.
> I think we could parse it initially as a function
On Thu, 9 May 2024 at 05:03, Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
I noticed a couple more things. This item:
Add functions to convert integers to hex and
On Thu, 23 May 2024 at 04:26, David Rowley wrote:
>
> On Sun, 19 May 2024 at 15:20, David Rowley wrote:
> >
> > I noticed that PlannedStmt.hasReturning and hasModifyingCTE have an
> > outdated comment now that MERGE supports RETURNING (per commit
> > c649fa24a)
> >
> > i.e. these two:
> >
> > >
On Fri, 17 May 2024 at 09:22, Dean Rasheed wrote:
>
> On Wed, 15 May 2024 at 02:14, Erik Wienhold wrote:
> >
> > plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
> >
> > Fixed in the attached patch.
> >
>
> Nice catch! The patch looks go
On Tue, 19 Mar 2024 at 11:53, Daniel Gustafsson wrote:
>
> I did notice a few mistakes in the --filter
> documentation portion for other keywords but that's unrelated to this patch,
> will fix them once this is in to avoid conflicts.
>
Attached is a patch for the --filter docs, covering the
On Sat, 8 Jun 2024 at 19:39, Ayush Vatsa wrote:
>
> > Attached is a patch for the --filter docs, covering the omissions I can see.
> Thanks Dean for working on this.
> I have reviewed the changes and they look good to me.
>
Thanks for checking. I have committed this now.
Regards,
Dean
501 - 532 of 532 matches
Mail list logo
