On Thu, Jan 14, 2016 at 3:25 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote:
>>> Vitaly Burovoy writes:
You can't now do something like
INSERT INTO foo (arraycol[2], arraycol[4]) VALUES(7, 11);
>
>>> Hm ... actually, you might want
On Thu, Jan 14, 2016 at 1:25 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote:
> >> Vitaly Burovoy writes:
> >>> You can't now do something like
> >>> INSERT INTO foo (arraycol[2], arraycol[4]) VALUES(7, 11);
>
> >> Hm ... actually, you migh
"David G. Johnston" writes:
> On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote:
>> Vitaly Burovoy writes:
>>> You can't now do something like
>>> INSERT INTO foo (arraycol[2], arraycol[4]) VALUES(7, 11);
>> Hm ... actually, you might want to try that before opining
> So what's the problem, then
On 1/14/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 1/14/16, Tom Lane wrote:
>>> It's more than syntactic sugar; you are going to have to invent
>>> semantics,
>>> as well, because it's less than clear what partial-field assignments
>>> should do.
>>>
>>> Assume a table with an int-array
On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote:
> Vitaly Burovoy writes:
> > On 1/14/16, Tom Lane wrote:
> >> It's more than syntactic sugar; you are going to have to invent
> semantics,
> >> as well, because it's less than clear what partial-field assignments
> >> should do.
> >>
> >> Assume
On 01/14/2016 03:00 PM, Marko Tiikkaja wrote:
On 2016-01-14 20:50, Vitaly Burovoy wrote:
On 1/14/16, Tom Lane wrote:
Assume a table with an int-array column, and consider
INSERT INTO foo SET arraycol[2] = 7, arraycol[4] = 11;
Right part is a column name, not an expression. Isn't it?
So "a
Vitaly Burovoy writes:
> On 1/14/16, Tom Lane wrote:
>> It's more than syntactic sugar; you are going to have to invent semantics,
>> as well, because it's less than clear what partial-field assignments
>> should do.
>>
>> Assume a table with an int-array column, and consider
>> INSERT INTO foo
On 2016-01-14 20:50, Vitaly Burovoy wrote:
On 1/14/16, Tom Lane wrote:
Assume a table with an int-array column, and consider
INSERT INTO foo SET arraycol[2] = 7, arraycol[4] = 11;
Right part is a column name, not an expression. Isn't it?
So "arraycol[2]" is not possible there.
I think the
On 1/14/16, Tom Lane wrote:
> Pavel Stehule writes:
Probably there is less risk than 7 years ago, but still creating own
syntax isn't the best idea. This is syntactic sugar only and different
from ANSi SQL or common standard.
>
> It's more than syntactic sugar; you are going to hav
On 2016-01-14 20:33, Tom Lane wrote:
Pavel Stehule writes:
Probably there is less risk than 7 years ago, but still creating own
syntax isn't the best idea. This is syntactic sugar only and different
from ANSi SQL or common standard.
It's more than syntactic sugar; you are going to have to inv
Pavel Stehule writes:
>>> Probably there is less risk than 7 years ago, but still creating own
>>> syntax isn't the best idea. This is syntactic sugar only and different
>>> from ANSi SQL or common standard.
It's more than syntactic sugar; you are going to have to invent semantics,
as well, becau
2016-01-14 20:09 GMT+01:00 Marko Tiikkaja :
> On 2016-01-14 8:06 PM, Pavel Stehule wrote:
>
>> Probably there is less risk than 7 years ago, but still creating own
>> syntax
>> isn't the best idea. This is syntactic sugar only and different from ANSi
>> SQL or common standard.
>>
>
> So is RETURNI
>SET syntax for INSERT was brought up a few years ago here:
>http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com
>What do we think?
+1
this would save comments in long queries.
and usindg AS as style helper as suggested in the old post has its caveat:
On 2016-01-14 8:06 PM, Pavel Stehule wrote:
Probably there is less risk than 7 years ago, but still creating own syntax
isn't the best idea. This is syntactic sugar only and different from ANSi
SQL or common standard.
So is RETURNING, UPSERT, PL/PgSQL and many other useful features.
.m
--
S
2016-01-14 19:51 GMT+01:00 Robert Haas :
> On Thu, Jan 14, 2016 at 12:13 PM, Marko Tiikkaja wrote:
> > SET syntax for INSERT was brought up a few years ago here:
> >
> http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com
> >
> > From the discussion it s
On Thu, Jan 14, 2016 at 12:13 PM, Marko Tiikkaja wrote:
> SET syntax for INSERT was brought up a few years ago here:
> http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com
>
> From the discussion it seems that one committer was against, one committer
> w
Hi,
SET syntax for INSERT was brought up a few years ago here:
http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com
From the discussion it seems that one committer was against, one
committer was not against, and one committer saw something good in t
Heikki Linnakangas escribió:
> I do understand the point, though - it's much easier to edit and debug
> long statements when the value is close to the column name. I find that
> the INSERT .. SELECT makes that a lot nicer:
>
> INSERT INTO t
> (col1,col2,col3,col4,col5,col6,col7,col8,col9,col10,co
Rob Wultsch wrote:
-1 PostgreSQL isn't MySQL!
For an insert with many columns or with large value this syntax can
significantly improve readability. So it wasn't invented here, so
what? I don't see a downside to allowing this syntax other than MySQL
used it first, and there are multiple
>
> For an insert with many columns or with large value this syntax can
> significantly improve readability. So it wasn't invented here, so
> what? I don't see a downside to allowing this syntax other than MySQL
> used it first, and there are multiple upsides (readability, easier
> transitions).
>
On Tue, Aug 25, 2009 at 10:36 AM, Pavel Stehule wrote:
> 2009/8/25 Rob Wultsch :
>> Given the recent discussion of "DELETE syntax on JOINS" I thought it
>> might be interesting to bring a bit MySQL syntax that is in somewhat
>> widespread use, generally create somewhat cleaner code and I imagine
>
Pavel Stehule wrote:
> 2009/8/25 Rob Wultsch :
>> Given the recent discussion of "DELETE syntax on JOINS" I thought it
>> might be interesting to bring a bit MySQL syntax that is in somewhat
>> widespread use, generally create somewhat cleaner code and I imagine
>> would not break much if implemen
2009/8/25 Rob Wultsch :
> Given the recent discussion of "DELETE syntax on JOINS" I thought it
> might be interesting to bring a bit MySQL syntax that is in somewhat
> widespread use, generally create somewhat cleaner code and I imagine
> would not break much if implemented.
>
> MySQL allows INSER
23 matches
Mail list logo
