From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Remove absolete function TupleDescGetSlot(). |
Date: | 2018-09-26 19:35:25 |
Message-ID: | 20180926193525.7nbw6tnb35xcgtm4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Hi,
On 2018-09-26 12:41:38 +0900, Michael Paquier wrote:
> On Tue, Sep 25, 2018 at 06:42:51PM -0700, Andres Freund wrote:
> > My point is that FuncCallContext->slot isn't actually all that related
> > to TupleDescGetSlot() and could be used entirely independently.
>
> That's fair. Why not just replacing the existing comment with something
> like "slot can be used in your own context to store tuple values,
> useful in the context of user-defined SRFs"? Just my 2c.
I've tried to do search for users of FuncCallContext->slot and couldn't
find anything. Therefore I'm more inclined to drop it too - just about
all cases where it's useful seem to require a more extensive
datastructure around anyway. Unless somebody protests I'm going to that
in a few - if somebody later in the cycle signals a need for it, we can
still revert that part.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-26 20:28:52 | Re: pgsql: Incorporate strerror_r() into src/port/snprintf.c, too. |
Previous Message | Peter Eisentraut | 2018-09-26 18:53:13 | pgsql: Recurse to sequences on ownership change for all relkinds |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-26 19:48:43 | Re: pgbench's expression parsing & negative numbers |
Previous Message | Daniel Verite | 2018-09-26 19:23:58 | Re: transction_timestamp() inside of procedures |