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 tag. In fact, I'm pretty sure it was a *bad* idea ---
> > what will happen if we ever create a statement actually named UPSERT?
> >
> > I think we should fix this by ripping out the variant tag, not trying
> > to propagate it everywhere it would need to go. Cute ideas are not
> > the same as good ideas.
>
> I'm not particularly worried about conflicting with a potential future
> UPSERT command. But I do see no corresponding benefit in having a
> differerent command tag, so I'm inclined to agree that ripping it out is
> likely the best way forward.
>
> 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. As I said elsewhere, I'm not even running
commands. I'm not really set on having the tag be different.
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 row? Seriously, who has OIDs in user tables
anymore? Surely we wouldn't try to do that for INSERT ON CONFLICT DO
UPDATE at all ... if anyone wants that functionality, they can use
RETURNING, which is far saner.
As for PQcmdTuples, what would a single number returned mean? Are we
returning the sum of both inserted and updated tuples? Isn't this a bit
odd? If the number is useful, then perhaps we should distinguish the
cases; and if it's not useful, why not just return zero?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services