|From:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|To:||Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>|
|Cc:||Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: MAP syntax for arrays|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 08/05/18 18:11, Ildar Musin wrote:
> On 08.05.2018 17:15, Peter Eisentraut wrote:
>> On 5/8/18 09:19, Chapman Flack wrote:
>>> On 05/08/2018 08:57 AM, Ildar Musin wrote:
>>>> select map (pow(2, x) - 1 for x in array[1,2,3,4,5]);
>>> I wonder how efficient an implementation would be possible
>>> strictly as a function, without grammar changes?
>> Yeah, you can pass a function to another function (using regprocedure
>> or just oid), so this should be possible entirely in user space.
> The problem with this approach is that extension should either have
> single map() function with input and output type of anyarray which
> cannot be used when user needs to map int to text for example. Or
> the other way there should be a set of map functions for different
> intput/output types.
> Another thing is that this approach is not as versatile since user need
> to create a function before running map, while with the proposed patch
> they could run arbitrary expression over the array directly.
The consensus on this seems to be that we don't want this. Yeah, it's a
handy syntax, but it's not that much better than using a subselect or a
writing a user-defined function. And there's risk of future conflicts
with the SQL standard. I'll mark this as "Rejected" in the commitfest.
|Next Message||Kyotaro HORIGUCHI||2018-07-19 09:23:05||Re: documentation about explicit locking|
|Previous Message||Heikki Linnakangas||2018-07-19 08:57:25||Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket|