Re: SET syntax in INSERT

On Thu, Jan 14, 2016 at 1:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)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.

David J.

David J.