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
Hello,
Here is a new version of the patch that applies to HEAD.
It also adds some regression tests for overriding {system,user} values
based on Wenjing Zeng's work.
Gareth
On Thu, 14 Jul 2022 at 22:40, Jacob Champion wrote:
>
> On Thu, Apr 7, 2022 at 11:29 AM Marko Tiikkaja wrote:
> > I can h
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
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
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
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
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
Hello Rachel,
On Wed, 22 Sept 2021 at 17:13, Rachel Heaton wrote:
>
> > 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 p
> 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
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
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
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
> 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
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 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
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
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
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
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 documentation have been
> > expanded.
>
> Per the auto
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
> 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 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-
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 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
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 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 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
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
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
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
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
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
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 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 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()
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.
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 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
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 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.
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
42 matches
Mail list logo
