On Thu, Jan 14, 2016 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Vitaly Burovoy <vitaly.burovoy@gmail.com> 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? It seems like a decision has already been > made.
Yeah, but is it a decision that we might later find to be at odds with a future SQL standard? The more places we embed that behavior, the more risk we take.
While I agree with the sentiment I'm not seeing the added risk introduced as being a major blocker if the syntactic sugar is indeed popular and otherwise desirable from a code maintenance standpoint. If the standard introduces a contradictory concept that we need to address we can do so. As we've already defined this specific behavior any conflict will likely result in the already defined behavior changing since having the same overall concept implemented differently for "VALUES" compared to "SET" would be undesirable. If we end up changing that whether we "doubled-down" by implementing "SET" seems immaterial.
The question, then, is whether there is any behavior that needs to be uniquely defined for SET that doesn't already come into play when using VALUES or SELECT? I cannot think of any but given the somewhat clandestine nature of your first example maybe you know of others.