Re: Use get_call_result_type() more widely - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Use get_call_result_type() more widely
Date
Msg-id CA+Tgmobv2cT=1mYR=UaEMMW-MbcGgN7xEv=XPEJo8yOEmWOg7w@mail.gmail.com
Whole thread Raw
In response to Re: Use get_call_result_type() more widely  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Use get_call_result_type() more widely  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 19, 2022 at 2:07 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On the other hand, the measurements have shown that going through the
> function is significantly slower.  So I kinda like the judgement call
> that Michael and Bharath have made: change to use the function when
> performance is not an issue, and keep the verbose coding otherwise.

Seems fairly arbitrary to me. The ones used for monitoring queries
aren't likely to be run often enough that it matters, but in theory
it's possible that they could be. Many of the ones supposedly not used
for monitoring queries could reasonably be so used, too. You can get
any answer you want by making arbitrary assumptions about which ones
are likely to be used frequently and how frequently they're likely to
be used, and I think different people evaluating the list
independently of each other and with no knowledge of each others work
would likely reach substantially different conclusions, ranging all
the way from "do them all this way" to "do them all the other way" and
various positions in the middle.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Use get_call_result_type() more widely
Next
From: Robert Haas
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity