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
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 |