Andres Freund wrote:
> This is implemented using a new infrastructure called "speculative
> insertion". It is an optimistic variant of regular insertion that first
> does a pre-check for existing tuples and then attempts an insert. If a
> violating tuple was inserted concurrently, the speculativel
On 27 May 2015 at 15:06, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > What I think should happen is that the command tag should vary according
> to
> > whether an INSERT or an UPDATE was performed, so we get a visible
> > difference without any new tags.
>
> The problem with doing that is tha
Simon Riggs wrote:
> What I think should happen is that the command tag should vary according to
> whether an INSERT or an UPDATE was performed, so we get a visible
> difference without any new tags.
The problem with doing that is that the same command might have updated
some tuples and inserted
On 22 May 2015 at 00:28, Alvaro Herrera wrote:
> > On the other hand, this was noticed because Alvaro just argued that it
> > *should* have a new command tag. Alvaro, where do you see the advantage?
>
> Well, I was just skimming nearby code and noticed that CreateCommandTag
> hadn't been updated
> Andres Freund wrote:
> > Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
>
Few comments/questions:
1.
insert.sgml
+ column. For example, INSERT ... ON CONFLICT DO UPDATE
+ tab SET table_name.col = 1 is invalid (this follows the general
+ behavior for UPDATE).
Here in
On 2015-05-22 12:23:32 -0700, Peter Geoghegan wrote:
> On Thu, May 21, 2015 at 5:51 PM, Peter Geoghegan wrote:
> >> So I think we're good with ripping it out. Peter?
> >
> > I'll come up with a patch.
>
> Attached patch rips the command tag out.
Pushed.
--
Sent via pgsql-hackers mailing list
On Thu, May 21, 2015 at 5:51 PM, Peter Geoghegan wrote:
>> So I think we're good with ripping it out. Peter?
>
> I'll come up with a patch.
Attached patch rips the command tag out.
--
Peter Geoghegan
From 3b50dcd242223c909bdedf20d9b7cb94ba2ff78e Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
D
On Thu, May 21, 2015 at 5:48 PM, Andres Freund wrote:
>
>> If the number is useful, then perhaps we should distinguish the cases;
>> and if it's not useful, why not just return zero?
>
> There's libraries/frameworks checking if an insert succeeded by looking
> at that number, and it seems like a b
On 2015-05-21 20:28:41 -0300, Alvaro Herrera wrote:
> That said, I'm not sure about having it be the same, either: first, I
> don't think we need to update the fe-exec.c code at all -- I mean, all
> the things I see there are very old compatibility stuff; reporting the
> OID of the just-inserted ro
On Thu, May 21, 2015 at 4:32 PM, Alvaro Herrera
wrote:
> (But as I said earlier, it doesn't really affect me either way, so feel
> free to rip it out.)
That appears to be the consensus. Should I post a patch?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Alvaro Herrera wrote:
> That said, I'm not sure about having it be the same, either: first, I
> don't think we need to update the fe-exec.c code at all -- I mean, all
> the things I see there are very old compatibility stuff;
(But as I said earlier, it doesn't really affect me either way, so feel
Andres Freund wrote:
> On 2015-05-20 21:22:08 -0400, Tom Lane wrote:
> > Not to mention that several places in libpq/fe-exec.c should be
> > taught about this new tag. And who-knows-what in other client-side
> > libraries. I am not really sure that it was a good idea to invent
> > this command ta
On 05/21/2015 05:08 AM, Peter Geoghegan wrote:
On Wed, May 20, 2015 at 6:22 PM, Tom Lane wrote:
I am not really sure that it was a good idea to invent
this command tag. In fact, I'm pretty sure it was a *bad* idea ---
what will happen if we ever create a statement actually named UPSERT?
Why
On May 20, 2015, at 9:22 PM, Tom Lane wrote:
> Andres Freund writes:
>> You realize there's other instances of this in the same damn function?
>
> Not to mention that several places in libpq/fe-exec.c should be
> taught about this new tag. And who-knows-what in other client-side
> libraries. I
On Wed, May 20, 2015 at 6:12 PM, Andres Freund wrote:
> You realize there's other instances of this in the same damn function?
I was misled by the argument name, "parsetree" -- in the past,
CreateCommandTag() actually only processed raw parse trees. Beyond
that, I wasn't aware that it is possible
On Wed, May 20, 2015 at 6:22 PM, Tom Lane wrote:
> I am not really sure that it was a good idea to invent
> this command tag. In fact, I'm pretty sure it was a *bad* idea ---
> what will happen if we ever create a statement actually named UPSERT?
Why would we invent a statement actually named UP
On 2015-05-20 21:22:08 -0400, Tom Lane wrote:
> Not to mention that several places in libpq/fe-exec.c should be
> taught about this new tag. And who-knows-what in other client-side
> libraries. I am not really sure that it was a good idea to invent
> this command tag. In fact, I'm pretty sure it
Andres Freund writes:
> You realize there's other instances of this in the same damn function?
Not to mention that several places in libpq/fe-exec.c should be
taught about this new tag. And who-knows-what in other client-side
libraries. I am not really sure that it was a good idea to invent
thi
On 2015-05-20 15:21:49 -0700, Peter Geoghegan wrote:
> On Wed, May 20, 2015 at 3:14 PM, Peter Geoghegan wrote:
> > I think you're right. The initial commit neglected to update that, and
> > only handled it from ProcessQuery(). So it works for PlannedStmts, not
> > raw parse trees.
>
> Attached pa
On Wed, May 20, 2015 at 3:14 PM, Peter Geoghegan wrote:
> I think you're right. The initial commit neglected to update that, and
> only handled it from ProcessQuery(). So it works for PlannedStmts, not
> raw parse trees.
Attached patch fixes this. Thanks for the report.
--
Peter Geoghegan
diff
On Wed, May 20, 2015 at 3:09 PM, Alvaro Herrera
wrote:
>> Are you using an old psql? I thought that that would just result in no
>> command tag being displayed.
>
> Well, I'm using an editor to read the code of CreateCommandTag(), not
> executing anything. I guess that function needs an update, t
Peter Geoghegan wrote:
> On Wed, May 20, 2015 at 2:58 PM, Alvaro Herrera
> wrote:
> > Hm, I just realized that the command tag for INSERT ON CONFLICT is still
> > just INSERT. Is that okay? To me, the behavior is different enough
> > that it should have its own tag. I'm not too set on this, but
On Wed, May 20, 2015 at 2:58 PM, Alvaro Herrera
wrote:
> Hm, I just realized that the command tag for INSERT ON CONFLICT is still
> just INSERT. Is that okay? To me, the behavior is different enough
> that it should have its own tag. I'm not too set on this, but maybe
> others share this opinio
On 2015-05-20 18:58:16 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
>
> Hm, I just realized that the command tag for INSERT ON CONFLICT is still
> just INSERT. Is that okay? To me, the behavior is different enough
> that it sho
Andres Freund wrote:
> Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
Hm, I just realized that the command tag for INSERT ON CONFLICT is still
just INSERT. Is that okay? To me, the behavior is different enough
that it should have its own tag. I'm not too set on this, but maybe
others
25 matches
Mail list logo
