On 1/14/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Pavel Stehule <pavel.steh...@gmail.com> 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, 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 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. You can't now do something like INSERT INTO foo (arraycol[2], arraycol[4]) VALUES(7, 11); > I wonder what the other elements of the array will be set to, and what > the array dimensions will end up being. > > If there's a default expression for the array column, does that change > your answer? > > If you say "we'll apply the default and then perform the SET assignments", > what's your criterion for deciding that you *don't* need to evaluate the > default? If the default has side effects (think nextval()) this is a > user-visible choice. Default values can be explicitly set as they are set in UPDATE: INSERT INTO foo SET defcol = DEFAULT; > I don't say that these questions are unresolvable, but there is certainly > more here than meets the eye; and therefore there's a nonzero chance of > being blindsided if the SQL committee someday standardizes this syntax > and makes some different decisions about what it means. > > regards, tom lane Be honest I've dreamed about that syntax since I started to work with PG, so +1 -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
