>
> 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
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
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
> 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
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
> &g
> 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
> 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 targ
> 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 targ
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
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.
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
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
> o
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
13 matches
Mail list logo