Re: Outdated comments around HandleFunctionRequest - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Outdated comments around HandleFunctionRequest
Date
Msg-id 98c5cbd4-8929-b6c8-f87d-94c316ac9ef9@iki.fi
Whole thread Raw
In response to Re: Outdated comments around HandleFunctionRequest  (Heikki Linnakangas <hlinnaka@iki.fi>)
List 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




pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PoC plpgsql - possibility to force custom or generic plan
Next
From: Pavel Stehule
Date:
Subject: Re: PoC plpgsql - possibility to force custom or generic plan