Re: Possible marginally-incompatible change to array subscripting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible marginally-incompatible change to array subscripting
Date: 2015-12-23 03:25:03
Message-ID: 6483.1450841103@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> One could theoretically construct a custom "type" that followed more
> traditional semantics, but then you'd lose all the syntax... which I
> suspect would make any such "type" all but unusable. The other problem
> would be having it deal with any other data type, but at least there's
> ways you can work around that for the most part.

Yeah. We've speculated a bit about allowing other datatypes to have
access to the subscript syntax, which could be modeled as allowing
'a[b]' to be an overloadable operator. That seems possibly doable if
someone wanted to put time into it. However, that still leaves a
heck of a lot of functionality on the table, such as automatic creation of
array types corresponding to new scalar types, not to mention the parser's
understanding of "anyarray" vs "anyelement" polymorphism. I have no idea
how we might make those things extensible.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2015-12-23 04:53:36 Re: Getting sorted data from foreign server for merge join
Previous Message Tom Lane 2015-12-23 03:16:05 Re: [PROPOSAL] Backup and recovery of pg_statistic