Hello,
Attached is a patch that adds the option of using SET clause to specify
the columns and values in an INSERT statement in the same manner as that
of an UPDATE statement.
A simple example that uses SET instead of a VALUES() clause:
INSERT INTO t SET c1 = 'foo', c2 = 'bar', c3 = 'baz';
Valu
Hello,
Attached is a patch that adds the option of using SET clause to specify
the columns and values in an INSERT statement in the same manner as that
of an UPDATE statement.
A simple example that uses SET instead of a VALUES() clause:
INSERT INTO t SET c1 = 'foo', c2 = 'bar', c3 = 'baz';
Valu
On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer
wrote:
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
>
Cool! Thanks for working on this, I'd love to see the syntax in P
Hi Marko,
> On 17/07/2019, at 5:52 PM, Marko Tiikkaja wrote:
>
> On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer
> wrote:
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
Hello.
At Thu, 18 Jul 2019 11:30:04 +1200, Gareth Palmer
wrote in
> Hi Marko,
>
> > On 17/07/2019, at 5:52 PM, Marko Tiikkaja wrote:
> >
> > On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer
> > wrote:
> > Attached is a patch that adds the option of using SET clause to specify
> > the columns
Hi Kyotaro,
Thank-you for looking at the patch.
> On 18/07/2019, at 6:54 PM, Kyotaro Horiguchi wrote:
>
> Hello.
>
> If I'm not missing something, "SELECT " without
> having FROM clause doesn't need to be tweaked. Thus
> insert_set_clause is useless and all we need here would be
> something li
Patch conflict with this assertion
Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE);
src/backend/parser/parse_expr.c line 1570
The new status of this patch is: Waiting on Author
Hi Ibrar,
> On 16/08/2019, at 7:14 AM, Ibrar Ahmed wrote:
>
> Patch conflict with this assertion
> Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE);
>
> src/backend/parser/parse_expr.c line 1570
>
> The new status of this patch is: Waiting on Author
Thank-you for reviewing the patch.
On Wed, Jul 17, 2019 at 10:00 AM Gareth Palmer wrote:
>
> Hello,
>
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
>
> A simple example that uses SET instead of a VALUES()
On Fri, Aug 16, 2019 at 8:19 AM Amit Kapila wrote:
> On Wed, Jul 17, 2019 at 10:00 AM Gareth Palmer
> wrote:
> >
> > Hello,
> >
> > Attached is a patch that adds the option of using SET clause to specify
> > the columns and values in an INSERT statement in the same manner as that
> > of an UPDAT
On 2019-08-16 05:19, Amit Kapila wrote:
> I think this can be a handy feature in some cases as pointed by you,
> but do we really want it for PostgreSQL? In the last round of
> discussions as pointed by you, there doesn't seem to be a consensus
> that we want this feature. I guess before spending
On 18/08/2019 11:03, Peter Eisentraut wrote:
>
> a UNION b
>
> vs
>
> a UNION CORRESPONDING b
I have a WIP patch for CORRESPONDING [BY]. Is there any interest in me
continuing it? If so, I'll start another thread for it.
--
Vik Fearing
Vik Fearing writes:
> On 18/08/2019 11:03, Peter Eisentraut wrote:
>> a UNION b
>> vs
>> a UNION CORRESPONDING b
> I have a WIP patch for CORRESPONDING [BY]. Is there any interest in me
> continuing it? If so, I'll start another thread for it.
CORRESPONDING is in the SQL standard, so in theory
Peter Eisentraut writes:
> What I don't like about the syntax is that it kind of breaks the
> notional processing model of INSERT in a fundamental way.
Agreed. I really don't like that this only works for a VALUES-like case
(and only the one-row form at that). It's hard to see it as anything
bu
Hi Tom,
> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> What I don't like about the syntax is that it kind of breaks the
>> notional processing model of INSERT in a fundamental way.
>
> Agreed. I really don't like that this only works for a VALUES-like case
> (and
On 4/23/20 8:04 PM, Gareth Palmer wrote:
Thank you for the review, attached is v7 of the patch which should
apply correcly to HEAD.
This version now uses it's own production rule for the SET clause to
avoid the issue with MultiAssigmentRef nodes in the targetList.
Ibrar, Movead, you are the r
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Patch looks to me and works on my machine
73025140885c889410b9bf
On Sun, Aug 18, 2019 at 11:00 AM Tom Lane wrote:
> Perhaps the way to resolve Peter's objection is to make the syntax
> more fully like UPDATE:
>
> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-x-y-z
>
> (with the patch as-submitted corresponding to the case with an empty
> FR
On Fri, Nov 1, 2019 at 6:31 PM Robert Haas wrote:
> On Sun, Aug 18, 2019 at 11:00 AM Tom Lane wrote:
> > Perhaps the way to resolve Peter's objection is to make the syntax
> > more fully like UPDATE:
> >
> > INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-x-y-z
> >
> > (with t
> On 4/23/20 8:04 PM, Gareth Palmer wrote:
> >
> > Thank you for the review, attached is v7 of the patch which should
> > apply correcly to HEAD.
> >
Hello Gareth,
This patch no longer applies to HEAD, can you please submit a rebased version?
Thanks,
Rachel
,
>
> This patch no longer applies to HEAD, can you please submit a rebased version?
Attached is a rebased version that should apply to HEAD.
Gareth
> Thanks,
> Rachel
>
>
>
>
From 7e222b4068e445a723f1692c5cdeec99d498a161 Mon Sep 17 00:00:00 2001
From: Gareth Palmer
Gareth Palmer writes:
>> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>> Perhaps the way to resolve Peter's objection is to make the syntax
>> more fully like UPDATE:
>> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-x-y-z
>> (with the patch as-submitted corresponding to the
On Thu, Nov 14, 2019 at 9:20 PM Tom Lane wrote:
> Gareth Palmer writes:
> >> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
> >> Perhaps the way to resolve Peter's objection is to make the syntax
> >> more fully like UPDATE:
> >> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM
> tables-provid
Pantelis Theodosiou writes:
> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>>> Perhaps the way to resolve Peter's objection is to make the syntax
>>> more fully like UPDATE:
>>> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM
>>> tables-providing-x-y-z
> Regarding syntax and considering that it
> On 15/11/2019, at 10:20 AM, Tom Lane wrote:
>
> Gareth Palmer writes:
>>> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>>> Perhaps the way to resolve Peter's objection is to make the syntax
>>> more fully like UPDATE:
>>>INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-
> On 15/11/2019, at 10:20 AM, Tom Lane wrote:
>
> Gareth Palmer writes:
>>> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>>> Perhaps the way to resolve Peter's objection is to make the syntax
>>> more fully like UPDATE:
>>>INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-
> On 19/11/2019, at 5:05 PM, Gareth Palmer wrote:
>>
>> Since nobody has objected to this, I'm supposing that there's general
>> consensus that that design sketch is OK, and we can move on to critiquing
>> implementation details. I took a look, and didn't like much of what I saw.
Attached is a
On Fri, Nov 22, 2019 at 12:24:15PM +1300, Gareth Palmer wrote:
> Attached is an updated patch with for_locking_clause added, test-cases
> re-use existing tables and the comments and documentation have been
> expanded.
Per the automatic patch tester, documentation included in the patch
does not bui
n Sep 17 00:00:00 2001
From: Gareth Palmer
Date: Mon, 2 Dec 2019 10:59:40 +0000
Subject: [PATCH] Implement INSERT SET syntax
Allow the target column and values of an INSERT statement to be specified
using a SET clause in the same manner as that of an UPDATE statement.
The advantage of using the INSER
Justin Pryzby writes:
> You have to either include the pre-requisite patches as 0001, and your patch
> as
> 0002 (as I'm doing now), or name your patch something other than *.diff or
> *.patch, so cfbot doesn't think it's a new version of the patch to be tested.
This patch has been basically ign
On Wed, Mar 23, 2022 at 5:33 PM Tom Lane wrote:
>
> Justin Pryzby writes:
> > You have to either include the pre-requisite patches as 0001, and your
> > patch as
> > 0002 (as I'm doing now), or name your patch something other than *.diff or
> > *.patch, so cfbot doesn't think it's a new version
On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer
wrote:
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
>
Cool! Thanks for working on this, I'd love to see the syntax in P
Hi Marko,
> On 17/07/2019, at 5:52 PM, Marko Tiikkaja wrote:
>
> On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer
> wrote:
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
Hello.
At Thu, 18 Jul 2019 11:30:04 +1200, Gareth Palmer
wrote in
> Hi Marko,
>
> > On 17/07/2019, at 5:52 PM, Marko Tiikkaja wrote:
> >
> > On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer
> > wrote:
> > Attached is a patch that adds the option of using SET clause to specify
> > the columns
Hi Kyotaro,
Thank-you for looking at the patch.
> On 18/07/2019, at 6:54 PM, Kyotaro Horiguchi wrote:
>
> Hello.
>
> If I'm not missing something, "SELECT " without
> having FROM clause doesn't need to be tweaked. Thus
> insert_set_clause is useless and all we need here would be
> something li
Patch conflict with this assertion
Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE);
src/backend/parser/parse_expr.c line 1570
The new status of this patch is: Waiting on Author
Hi Ibrar,
> On 16/08/2019, at 7:14 AM, Ibrar Ahmed wrote:
>
> Patch conflict with this assertion
> Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE);
>
> src/backend/parser/parse_expr.c line 1570
>
> The new status of this patch is: Waiting on Author
Thank-you for reviewing the patch.
On Wed, Jul 17, 2019 at 10:00 AM Gareth Palmer wrote:
>
> Hello,
>
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
>
> A simple example that uses SET instead of a VALUES()
On Fri, Aug 16, 2019 at 8:19 AM Amit Kapila wrote:
> On Wed, Jul 17, 2019 at 10:00 AM Gareth Palmer
> wrote:
> >
> > Hello,
> >
> > Attached is a patch that adds the option of using SET clause to specify
> > the columns and values in an INSERT statement in the same manner as that
> > of an UPDAT
On 2019-08-16 05:19, Amit Kapila wrote:
> I think this can be a handy feature in some cases as pointed by you,
> but do we really want it for PostgreSQL? In the last round of
> discussions as pointed by you, there doesn't seem to be a consensus
> that we want this feature. I guess before spending
On 18/08/2019 11:03, Peter Eisentraut wrote:
>
> a UNION b
>
> vs
>
> a UNION CORRESPONDING b
I have a WIP patch for CORRESPONDING [BY]. Is there any interest in me
continuing it? If so, I'll start another thread for it.
--
Vik Fearing
Vik Fearing writes:
> On 18/08/2019 11:03, Peter Eisentraut wrote:
>> a UNION b
>> vs
>> a UNION CORRESPONDING b
> I have a WIP patch for CORRESPONDING [BY]. Is there any interest in me
> continuing it? If so, I'll start another thread for it.
CORRESPONDING is in the SQL standard, so in theory
Peter Eisentraut writes:
> What I don't like about the syntax is that it kind of breaks the
> notional processing model of INSERT in a fundamental way.
Agreed. I really don't like that this only works for a VALUES-like case
(and only the one-row form at that). It's hard to see it as anything
bu
Hi Tom,
> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> What I don't like about the syntax is that it kind of breaks the
>> notional processing model of INSERT in a fundamental way.
>
> Agreed. I really don't like that this only works for a VALUES-like case
> (and
Since this feature adds INSERT OVERRIDING SET syntax, it is recommended to add
some related testcases.
Regards
Wenjing
> 2021年9月22日 07:38，Rachel Heaton 写道：
>
>> On 4/23/20 8:04 PM, Gareth Palmer wrote:
>>>
>>> Thank you for the review, attached is v7 of the patch which should
>>> apply co
y SET a = t.a+20 FROM t;
+
+SELECT * FROM y;
+
DROP TABLE y;
--
--
2.17.1
>From 4c42f9fb4f4b596da9e1fc1b4d15009b6eb035a1 Mon Sep 17 00:00:00 2001
From: wenjing zeng
Date: Fri, 21 Jan 2022 17:24:51 +0800
Subject: [PATCH 2/2] Since this feature adds INSERT OVERRIDING SET syntax, it
is recommen
On Thu, Apr 7, 2022 at 11:29 AM Marko Tiikkaja wrote:
> I can help with review and/or other work here. Please give me a
> couple of weeks.
Hi Marko, did you get a chance to pick up this patchset? If not, no
worries; I can mark this RwF and we can try again in a future
commitfest.
Thanks,
--Jaco
>
> Thanks,
> --Jacob
>
>
>
>
From f1ab7edadac846883b9c12f02ecc6c64dd293060 Mon Sep 17 00:00:00 2001
From: Gareth Palmer
Date: Thu, 14 Jul 2022 01:47:17 +
Subject: [PATCH] Implement INSERT SET syntax
Allow the target column and values of an INSERT statement to be specified
using a SET clause in the same
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
Hi Tom,
On 12/3/19 4:44 AM, Gareth Palmer wrote:
On Sun, Dec 1, 2019 at 4:32 PM Michael Paquier wrote:
On Fri, Nov 22, 2019 at 12:24:15PM +1300, Gareth Palmer wrote:
Attached is an updated patch with for_locking_clause added, test-cases
re-use existing tables and the comments and documentati
David Steele writes:
> On 12/3/19 4:44 AM, Gareth Palmer wrote:
>> Attached is a fixed version.
> Does this version of the patch address your concerns?
No. I still find the reliance on a FROM clause being present
to be pretty arbitrary. Also, I don't believe that ruleutils.c
requires no change
I wrote:
> No doubt that's all fixable, but the realization that some cases of
> this syntax are *not* just syntactic sugar for standards-compliant
> syntax is giving me pause. Do we really want to get out front of
> the SQL committee on extending INSERT in an incompatible way?
One compromise tha
On 2020-03-24 18:57, Tom Lane wrote:
No doubt that's all fixable, but the realization that some cases of
this syntax are*not* just syntactic sugar for standards-compliant
syntax is giving me pause. Do we really want to get out front of
the SQL committee on extending INSERT in an incompatible wa
Peter Eisentraut writes:
> On 2020-03-24 18:57, Tom Lane wrote:
>> No doubt that's all fixable, but the realization that some cases of
>> this syntax are*not* just syntactic sugar for standards-compliant
>> syntax is giving me pause. Do we really want to get out front of
>> the SQL committee on
> On 26/03/2020, at 3:17 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> On 2020-03-24 18:57, Tom Lane wrote:
>>> No doubt that's all fixable, but the realization that some cases of
>>> this syntax are*not* just syntactic sugar for standards-compliant
>>> syntax is giving me pause. Do we
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
It builds failed by applying to the latest code version, and
Hi Movead,
> On 22/04/2020, at 2:40 PM, movead li wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:teste
57 matches
Mail list logo
