Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2016-03-09 Thread David Steele
On 12/23/15 9:15 PM, Michael Paquier wrote: On Mon, Dec 7, 2015 at 9:14 PM, Michael Paquier wrote: On Wed, Sep 2, 2015 at 6:19 AM, Marko Tiikkaja wrote: Hopefully nobody minds if I slip this to the commit fest that started today? The attached patch should address all the comments from the 9.

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2015-12-23 Thread Michael Paquier
On Mon, Dec 7, 2015 at 9:14 PM, Michael Paquier wrote: > > > On Wed, Sep 2, 2015 at 6:19 AM, Marko Tiikkaja wrote: >> >> Hopefully nobody minds if I slip this to the commit fest that started >> today? The attached patch should address all the comments from the 9.5 >> cycle. > > > All the previou

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2015-12-07 Thread Michael Paquier
On Wed, Sep 2, 2015 at 6:19 AM, Marko Tiikkaja wrote: > Hopefully nobody minds if I slip this to the commit fest that started > today? The attached patch should address all the comments from the 9.5 > cycle. > All the previous comments have been addressed. Perhaps some regression tests would ha

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2015-09-01 Thread Marko Tiikkaja
On 2015-09-01 23:19, I wrote: Hopefully nobody minds if I slip this to the commit fest that started today? The attached patch should address all the comments from the 9.5 cycle. Apparently the CF app will. Meh. Whatever. Ignore then, I guess. .m -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2015-09-01 Thread Marko Tiikkaja
Hi, Hopefully nobody minds if I slip this to the commit fest that started today? The attached patch should address all the comments from the 9.5 cycle. .m *** a/src/backend/parser/analyze.c --- b/src/backend/parser/analyze.c *** *** 2107,2118 transformUpdateTargetList(Parse

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2015-01-15 Thread Michael Paquier
On Thu, Jan 8, 2015 at 2:28 AM, Marko Tiikkaja wrote: > Yeah. (The CF entry is also set to Waiting on Author, which seems > appropriate.) Seeing nothing happening here for quite some time, marked as returned with feedback.. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2015-01-07 Thread Marko Tiikkaja
On 1/7/15 6:22 PM, Alvaro Herrera wrote: We're waiting for an updated version here, right? Yeah. (The CF entry is also set to Waiting on Author, which seems appropriate.) .marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: ht

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2015-01-07 Thread Alvaro Herrera
We're waiting for an updated version here, right? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http:

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2014-11-22 Thread Marko Tiikkaja
On 2014-11-22 18:02, Tom Lane wrote: Marko Tiikkaja writes: A common mistake is to try and qualify column references on the LHS of SET in UPDATE. The error message can be a bit cryptic at times, too. Perhaps, but this hint is not much of an improvement: HINT: Target column references in U

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2014-11-22 Thread Tom Lane
Marko Tiikkaja writes: > A common mistake is to try and qualify column references on the LHS of > SET in UPDATE. The error message can be a bit cryptic at times, too. Perhaps, but this hint is not much of an improvement: > HINT: Target column references in UPDATE must not be qualified becau

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2014-11-22 Thread Marko Tiikkaja
On 2014-11-22 05:11, Peter Geoghegan wrote: On Fri, Nov 21, 2014 at 7:49 PM, Marko Tiikkaja wrote: A common mistake is to try and qualify column references on the LHS of SET in UPDATE. I think that this is a good idea, but as written the patch doesn't handle aliases correctly: postgres=# cre

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2014-11-21 Thread Peter Geoghegan
On Fri, Nov 21, 2014 at 7:49 PM, Marko Tiikkaja wrote: > A common mistake is to try and qualify column references on the LHS of SET > in UPDATE. I think that this is a good idea, but as written the patch doesn't handle aliases correctly: postgres=# create table foo (val text); CREATE TABLE postg

[HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

2014-11-21 Thread Marko Tiikkaja
Hi, A common mistake is to try and qualify column references on the LHS of SET in UPDATE. The error message can be a bit cryptic at times, too. I've attached a patch to try and improve the situation a bit: =# create table foo(bar int); CREATE TABLE =# update foo set foo.bar = 1; ERROR: col