From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Corey Huinker <corey.huinker@gmail.com>,
        Andrew Dunstan <andrew@dunslane.net>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Error-safe user functions
In-reply-to: 
 <CA+Tgmob-qRQ1LhD+HEHSJ+_ypxrj+_aJSL43sttnrocbbFXowg@mail.gmail.com>
References: <3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru>
 <3190059.1665164276@sss.pgh.pa.us>
 <57b7cc2e-1215-3f43-84e4-6d9f8ad575df@dunslane.net>
 <CADkLM=djieyppZpKgveeDdt3QYLt+XQGHzpoa+Sd_Lwa5dDTWA@mail.gmail.com>
 <3049337.1669008405@sss.pgh.pa.us>
 <469338a3-da38-160f-23b9-813c261bc1d6@dunslane.net>
 <1677334.1669918475@sss.pgh.pa.us>
 <CA+TgmoY44nbY6Z7zbnQ1VwgDu79DbOHmh4o8K9cBu0OeC2Hndw@mail.gmail.com>
 <1695760.1669923671@sss.pgh.pa.us>
 <CA+TgmobpfOx0WT+ZG71eB5=JrKUi-VX7FwsVF6E8ps1WfKYYcQ@mail.gmail.com>
 <1703871.1669927782@sss.pgh.pa.us>
 <CA+TgmoaxLcxpLmFJ=QiOThfPRGLhRH+o2XZmVie2KOk5TKGbKg@mail.gmail.com>
 <1721519.1669934025@sss.pgh.pa.us>
 <CA+TgmoZ5tQz4sZfXOAK-wx7e2d2+pGg4EEc1TA4sb9gNMjm4Fw@mail.gmail.com>
 <1925585.1669990324@sss.pgh.pa.us>
 <02cf2f81-a776-37ff-291c-100480722a5c@dunslane.net>
 <CADkLM=cum4VxhnC5CfmpMB=RbJ4SKGfm-s3KkjA59xzwif0C8g@mail.gmail.com>
 <2006267.1670006761@sss.pgh.pa.us>
 <CA+Tgmob-qRQ1LhD+HEHSJ+_ypxrj+_aJSL43sttnrocbbFXowg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 02 Dec 2022 15:49:09 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2134306.1670015951.1@sss.pgh.pa.us>
Date: Fri, 02 Dec 2022 16:19:11 -0500
Message-ID: <2134307.1670015951@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2134307.1670015951%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 2, 2022 at 1:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The main objection I can see to this approach is that we only support
>> one context value per call, so you could not easily combine this
>> functionality with existing use-cases for the context field.

> I kind of wonder why we don't just add another member to FmgrInfo.
> It's 48 bytes right now and this would increase the size to 56 bytes,

This'd be FunctionCallInfoData not FmgrInfo.

I'm not terribly concerned about the size of FunctionCallInfoData,
but I am concerned about the number of cycles spent to initialize it,
because we do that pretty durn often.  So I don't really want to add
fields to it without compelling use-cases, and I don't see one here.

			regards, tom lane