On Thu, Jan 14, 2016 at 3:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "David G. Johnston" <david.g.johns...@gmail.com> writes: >> On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Vitaly Burovoy <vitaly.buro...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
