On 1/14/16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@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
