Re: Outdated comments around HandleFunctionRequest

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Outdated comments around HandleFunctionRequest
Date: 2017-04-06 06:12:25
Message-ID: 98c5cbd4-8929-b6c8-f87d-94c316ac9ef9@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/05/2017 10:58 AM, Heikki Linnakangas wrote:
> On 04/05/2017 04:05 AM, Andres Freund wrote:
>> PostgresMain() has the following blurb for fastpath functions:
>>
>> /*
>> * Note: we may at this point be inside an aborted
>> * transaction. We can't throw error for that until we've
>> * finished reading the function-call message, so
>> * HandleFunctionRequest() must check for it after doing so.
>> * Be careful not to do anything that assumes we're inside a
>> * valid transaction here.
>> */
>> and in HandleFunctionRequest() there's:
>>
>> * INPUT:
>> * In protocol version 3, postgres.c has already read the message body
>> * and will pass it in msgBuf.
>> * In old protocol, the passed msgBuf is empty and we must read the
>> * message here.
>>
>> which is not true anymore. Followed by:
>>
>> /*
>> * Now that we've eaten the input message, check to see if we actually
>> * want to do the function call or not. It's now safe to ereport(); we
>> * won't lose sync with the frontend.
>> */
>>
>> which is also not really meaningful, because there's no previous code in
>> the function.
>
> You're right, I missed those comments in commit 2b3a8b20c2.
>
> In fact, HandleFunctionRequest() now always return 0, so we can also
> remove the dead code to check the return value from the caller. Barring
> objections, I'll commit the attached to do that and fix the comments.

Committed, thanks!

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2017-04-06 06:17:12 Re: PoC plpgsql - possibility to force custom or generic plan
Previous Message Pavel Stehule 2017-04-06 06:09:29 Re: PoC plpgsql - possibility to force custom or generic plan