Re: MAP syntax for arrays

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
Date: 2018-07-19 09:14:17
Message-ID: 14ac5bbe-e9fb-2ce4-2d6d-698f8da29449@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
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