On Thu, Jan 14, 2016 at 3: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.
I don't see it. If the SQL standard committee defines foo[2] to mean
something other than array access to element 2 of foo, then we've got
a problem, but they're not going to define it different ways for
SELECT, INSERT, and UPDATE. And even if they did, we're certainly not
going to want those to mean different and incompatible things. So I
don't think doubling down on the syntax we already support loses
anything, really.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
