Alvaro Herrera writes:
> Andrew Gierth wrote:
> "Tom" == Tom Lane 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
Andrew Gierth wrote:
> > "Tom" == Tom Lane 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 th
> "Tom" == Tom Lane 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 just wo
Andrew Gierth writes:
> "Tom" == Tom Lane 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 using the composite value directly would
> "Tom" == Tom Lane 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
Andrew Gierth writes:
> "Tom" == Tom Lane 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 c
> "Tom" == Tom Lane 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 examples. The o
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. Th
Peter Geoghegan writes:
> On Tue, Apr 7, 2015 at 11:19 AM, Tom Lane 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
>
On Tue, Apr 7, 2015 at 12:01 PM, Peter Geoghegan 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 (which is a
disast
On Tue, Apr 7, 2015 at 11:19 AM, Tom Lane 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 how this would m
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
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
Atri Sharma 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 amount of time cle
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 a/doc
On Mon, Dec 15, 2014 at 7:50 PM, Atri Sharma 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 pgsql-hackers mai
On Mon, Dec 8, 2014 at 6:06 AM, Michael Paquier
wrote:
>
> On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane 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 with
On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane 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, but that may we
Marko Tiikkaja 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:
> C
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 UPD
On Fri, Oct 17, 2014 at 10:47 AM, Merlin Moncure wrote:
> On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
I think it wouldn't; Merlin is proposing that f would be taken as the
field name. A more realist
On Oct 17, 2014 6:16 PM, "Tom Lane" 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 column add
On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane 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
Merlin Moncure writes:
> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane 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 = (1,2); -- works
>> alter t
On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
> Marko Tiikkaja 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
Marko Tiikkaja 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 objection
On Fri, Oct 17, 2014 at 10:10 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja 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:
>
Merlin Moncure writes:
> On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma 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 target of the two patches is diffe
Merlin Moncure writes:
> On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja 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:
>
> So e.g.:
>UPDATE foo f SET f = ..;
> would resol
On 10/17/14 5:03 PM, Merlin Moncure wrote:
Hm, I didn't understand your objection:
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.
That's not correct: it should work exactly as 'select' does;
On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja 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
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 synt
On Fri, Oct 17, 2014 at 7:45 PM, Merlin Moncure wrote:
> On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
> >
> >
> > On Wednesday, October 15, 2014, Marti Raudsepp wrote:
> >>
> >> Hi
> >>
> >> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma
> wrote:
> >> > Please find attached a patch which
On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
>
>
> On Wednesday, October 15, 2014, Marti Raudsepp wrote:
>>
>> Hi
>>
>> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma wrote:
>> > Please find attached a patch which implements support for UPDATE table1
>> > SET(*)=...
>>
>> I presume you hav
On Wed, Oct 15, 2014 at 2:18 PM, Atri Sharma wrote:
>
> On Wednesday, October 15, 2014, Marti Raudsepp wrote:
>
>> Hi
>>
>> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma
>> wrote:
>> > Please find attached a patch which implements support for UPDATE table1
>> > SET(*)=...
>>
>> I presume you
On Wednesday, October 15, 2014, Marti Raudsepp wrote:
> Hi
>
> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma > 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 colu
Hi
On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma 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:
http://www.postgresql.org/message-id/1783.13990
37 matches
Mail list logo
