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:

> 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:

Reply via email to