From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Dmitry Dolgov <9erthalion6@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>,
        Arthur Zakirov <a.zakirov@postgrespro.ru>,
        Oleg Bartunov <obartunov@gmail.com>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        David Steele <david@pgmasters.net>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
In-reply-to: <20180107232030.wwanjyrauviqthze@alap3.anarazel.de>
References: <20171116114016.GA21162@zakirov.localdomain>
 <CA+q6zcUn+9OnuMh3Mvu=XaNpSmLGo2HrYcowgJqCDrhKifaz+A@mail.gmail.com>
 <20171119151350.GA23853@arthur.localdomain>
 <CA+q6zcXff34m4EskCiWdvc2BTx2J++w5gwSb43X0ejgg+sj9Wg@mail.gmail.com>
 <CAB7nPqSQFonLWsVr1OuDDd7NBHOBMNiHdvRwhxpkNV2W9-QUgg@mail.gmail.com>
 <CA+q6zcW52cJ-T3xrGm5BJ8ET6bcc0n3OYhM_oA9AQxAMZR2Otg@mail.gmail.com>
 <CA+q6zcX7W56i-k-_KK51ZQA3GZZKsFx0KzGAGm2rtC8M7948kQ@mail.gmail.com>
 <8809.1515031526@sss.pgh.pa.us>
 <CA+q6zcVuBkjWWYixH8ERPkaQiA9daA!YmHTSRn=jn_Ajrzp1=Ug@mail.gmail.com>
 <5571.1515364740@sss.pgh.pa.us>
 <20180107232030.wwanjyrauviqthze@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sun, 07 Jan 2018 15:20:30 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2243.1515368089.1@sss.pgh.pa.us>
Date: Sun, 07 Jan 2018 18:34:49 -0500
Message-ID: <2244.1515368089@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2018-01-07 17:39:00 -0500, Tom Lane wrote:
>> Now on the other hand, maybe the right way to go is to embrace a similar
>> approach to what I did for plpgsql param eval, and let the datatype
>> control what gets generated as the expression execution step.

> I'll note that I'm not convinced that the goal this paragraph states and
> having the datatype control the entire expression step are full
> dependent on each other. It seems quite possible to have
> ExecInitSubscriptingRef() call a datatype specific function that returns
> C callbacks.

Yeah, that's a good point.  We could define the compile support function
as simply being allowed to examine the expression tree and give back
the address of the callback function to use, with the rest of the compiled
expression structure being predetermined.  The more general approach would
only be useful if you imagine some sort of high-performance extension that
wants to compile specialized expr steps for its subscripting activity.
Probably the need for that is pretty far away yet.

BTW, if you wanted to change the way plpgsql param callbacks work to be
like this design (ie push the actual generation of the ExprStep back into
core, with plpgsql just supplying a callback address), I wouldn't object.

			regards, tom lane