Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-08 Thread Andrew Gierth
Tom == Tom Lane t...@sss.pgh.pa.us writes: Tom I spent a fair amount of time cleaning this patch up to get it Tom into committable shape, but as I was working on the documentation Tom I started to lose enthusiasm for it, because I was having a hard Tom time coming up with compelling

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-08 Thread Andrew Gierth
Tom == Tom Lane t...@sss.pgh.pa.us writes: Now this I think is wrong; I think it's just as robust against schema changes as using the composite value directly would be. Consider the case where foo and reference_foo match with the exception of dropped columns; the code as it is should

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-08 Thread Alvaro Herrera
Andrew Gierth wrote: Tom == Tom Lane t...@sss.pgh.pa.us writes: Tom Right, but we should be trying to move in that direction. I see Tom your point though that (*) is more notationally consistent with Tom that case. Maybe we should be looking at trying to implement T641 Tom in full and

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-08 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Andrew Gierth wrote: Tom == Tom Lane t...@sss.pgh.pa.us writes: Tom Right, but we should be trying to move in that direction. I see Tom your point though that (*) is more notationally consistent with Tom that case. Maybe we should be looking

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-08 Thread Andrew Gierth
Tom == Tom Lane t...@sss.pgh.pa.us writes: One example that comes up occasionally (and that I've had to do myself more than once) is this: given a table foo and another with identical schema reference_foo, apply appropriate inserts, updates and deletes to table foo to make the content of

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-08 Thread Tom Lane
Andrew Gierth and...@tao11.riddles.org.uk writes: Tom == Tom Lane t...@sss.pgh.pa.us writes: Tom I spent a fair amount of time cleaning this patch up to get it Tom into committable shape, but as I was working on the documentation Tom I started to lose enthusiasm for it, because I was having

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-08 Thread Tom Lane
Andrew Gierth and...@tao11.riddles.org.uk writes: Tom == Tom Lane t...@sss.pgh.pa.us writes: Tom and not at all robust against schema changes (the same problem as Tom with the patch's approach to UPDATE). Now this I think is wrong; I think it's just as robust against schema changes as

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-07 Thread Tom Lane
Atri Sharma atri.j...@gmail.com writes: Please find attached latest version of UPDATE (*) patch.The patch implements review comments and Tom's gripe about touching transformTargetList is addressed now. I have added regression tests and simplified parser representation a bit. I spent a fair

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-07 Thread Tom Lane
I wrote: So I'm feeling that this may not be a good idea, or at least not a good implementation of the idea. I'm inclined to reject the patch rather than lock us into something that is not standard and doesn't really do what people would be likely to want. BTW, a potentially workable fix to

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-07 Thread Peter Geoghegan
On Tue, Apr 7, 2015 at 12:01 PM, Peter Geoghegan p...@heroku.com wrote: I still don't like the idea of supporting this, though. I'm not aware of any other system allowing something like this for either MERGE or a non-standard UPSERT. That includes MySQL, BTW. Only their REPLACE statement

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-07 Thread Peter Geoghegan
On Tue, Apr 7, 2015 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote: If we were to go in this direction, it would be nice to at the same time add a similar whole-record syntax for INSERT. I'm not sure exactly what that should look like though. Also, again, we ought to be paying attention to

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-07 Thread Alvaro Herrera
Tom Lane wrote: I spent a fair amount of time cleaning this patch up to get it into committable shape, but as I was working on the documentation I started to lose enthusiasm for it, because I was having a hard time coming up with compelling examples. The originally proposed motivation was

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-07 Thread Tom Lane
Peter Geoghegan p...@heroku.com writes: On Tue, Apr 7, 2015 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote: If we were to go in this direction, it would be nice to at the same time add a similar whole-record syntax for INSERT. I'm not sure exactly what that should look like though. Also,

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-04-07 Thread Jim Nasby
On 4/7/15 2:00 PM, Alvaro Herrera wrote: Tom Lane wrote: I spent a fair amount of time cleaning this patch up to get it into committable shape, but as I was working on the documentation I started to lose enthusiasm for it, because I was having a hard time coming up with compelling examples.

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-02-13 Thread Atri Sharma
Hi all, Sorry for the delay. Please find attached latest version of UPDATE (*) patch.The patch implements review comments and Tom's gripe about touching transformTargetList is addressed now. I have added regression tests and simplified parser representation a bit. Regards, Atri diff --git

Re: [HACKERS] Support UPDATE table SET(*)=...

2015-01-14 Thread Michael Paquier
On Mon, Dec 15, 2014 at 7:50 PM, Atri Sharma atri.j...@gmail.com wrote: I have moved patch to current CF and marked it as Waiting on Author since I plan to resubmit after addressing the concerns. Nothing happened in the last month, so marking as returned with feedback. -- Michael -- Sent via

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-12-15 Thread Atri Sharma
On Mon, Dec 8, 2014 at 6:06 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane t...@sss.pgh.pa.us wrote: I think what's likely missing here is a clear design for the raw parse tree representation (what's returned by the bison grammar). The patch

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-12-07 Thread Michael Paquier
On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane t...@sss.pgh.pa.us wrote: I think what's likely missing here is a clear design for the raw parse tree representation (what's returned by the bison grammar). The patch seems to be trying to skate by without creating any new parse node types or fields,

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-11-25 Thread Tom Lane
Marko Tiikkaja ma...@joh.to writes: On 10/15/14, 10:02 AM, Atri Sharma wrote: Please find attached a patch which implements support for UPDATE table1 SET(*)=... I've had a few looks at this patch and I have a few comments: 1) This doesn't work for the zero-column table case at all:

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-29 Thread Marko Tiikkaja
Hi Atri, Sorry for the delay. With pgconf.eu and all, it's been very hard to find the time to look at this. On 10/15/14, 10:02 AM, Atri Sharma wrote: Please find attached a patch which implements support for UPDATE table1 SET(*)=... The patch supports both UPDATE table SET(*)=(a,b,c) and

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-22 Thread Merlin Moncure
On Fri, Oct 17, 2014 at 10:47 AM, Merlin Moncure mmonc...@gmail.com wrote: On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote: I think it wouldn't; Merlin is

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Merlin Moncure
On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma atri.j...@gmail.com wrote: On Wednesday, October 15, 2014, Marti Raudsepp ma...@juffo.org wrote: Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma atri.j...@gmail.com wrote: Please find attached a patch which implements support for UPDATE table1

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Atri Sharma
On Fri, Oct 17, 2014 at 7:45 PM, Merlin Moncure mmonc...@gmail.com wrote: On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma atri.j...@gmail.com wrote: On Wednesday, October 15, 2014, Marti Raudsepp ma...@juffo.org wrote: Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Marko Tiikkaja
On 10/17/14 4:15 PM, Merlin Moncure wrote: Any particular reason why you couldn't have just done: UPDATE table1 SET * = a,b,c, ... That just looks wrong to me. I'd prefer (*) = .. over that any day. UPDATE table1 t SET t = (SELECT (a,b,c)::t FROM...); seems cleaner than the proposed

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Merlin Moncure
On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja ma...@joh.to wrote: On 10/17/14 4:15 PM, Merlin Moncure wrote: Any particular reason why you couldn't have just done: UPDATE table1 SET * = a,b,c, ... That just looks wrong to me. I'd prefer (*) = .. over that any day. UPDATE table1 t

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Marko Tiikkaja
On 10/17/14 5:03 PM, Merlin Moncure wrote: Hm, I didn't understand your objection: quoting So e.g.: UPDATE foo f SET f = ..; would resolve to the table, despite there being a column called f? That would break backwards compatibility. /quoting That's not correct: it should work exactly as

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja ma...@joh.to wrote: I don't know about Tom, but I didn't like that: http://www.postgresql.org/message-id/5364c982.7060...@joh.to Hm, I didn't understand your objection: quoting So e.g.: UPDATE foo

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma atri.j...@gmail.com wrote: Thanks for the links, but this patch only targets SET(*) case, which, if I understand correctly, the patch you mentioned doesn't directly handle (If I understand correctly, the

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Merlin Moncure
On Fri, Oct 17, 2014 at 10:10 AM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja ma...@joh.to wrote: I don't know about Tom, but I didn't like that: http://www.postgresql.org/message-id/5364c982.7060...@joh.to Hm,

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Tom Lane
Marko Tiikkaja ma...@joh.to writes: local:marko=#* create table foo(f int); CREATE TABLE local:marko=#* update foo f set f=1; UPDATE 0 This query would change meaning with your suggestion. I think it wouldn't; Merlin is proposing that f would be taken as the field name. A more realistic

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Merlin Moncure
On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote: Marko Tiikkaja ma...@joh.to writes: local:marko=#* create table foo(f int); CREATE TABLE local:marko=#* update foo f set f=1; UPDATE 0 This query would change meaning with your suggestion. I think it wouldn't; Merlin is

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote: I think it wouldn't; Merlin is proposing that f would be taken as the field name. A more realistic objection goes like this: create table foo(f int, g int); update foo x set x =

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Merlin Moncure
On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote: I think it wouldn't; Merlin is proposing that f would be taken as the field name. A more realistic objection goes

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-17 Thread Marti Raudsepp
On Oct 17, 2014 6:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: A more realistic objection goes like this: create table foo(f int, g int); update foo x set x = (1,2); -- works alter table foo add column x int; update foo x set x = (1,2,3); -- no longer works It's not a real good thing if a

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-15 Thread Marti Raudsepp
Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma atri.j...@gmail.com wrote: Please find attached a patch which implements support for UPDATE table1 SET(*)=... I presume you haven't read Tom Lane's proposal and discussion about multiple column assignment in UPDATE:

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-15 Thread Atri Sharma
On Wednesday, October 15, 2014, Marti Raudsepp ma...@juffo.org wrote: Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma atri.j...@gmail.com javascript:; wrote: Please find attached a patch which implements support for UPDATE table1 SET(*)=... I presume you haven't read Tom Lane's

Re: [HACKERS] Support UPDATE table SET(*)=...

2014-10-15 Thread Atri Sharma
On Wed, Oct 15, 2014 at 2:18 PM, Atri Sharma atri.j...@gmail.com wrote: On Wednesday, October 15, 2014, Marti Raudsepp ma...@juffo.org wrote: Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma atri.j...@gmail.com wrote: Please find attached a patch which implements support for UPDATE