On Sun, Jul 8, 2018 at 11:48 AM, Haribabu Kommi
<kommi.harib...@gmail.com> wrote:
>
> On Fri, Jul 6, 2018 at 3:22 AM Fujii Masao <masao.fu...@gmail.com> wrote:
>>
>> On Wed, Jul 4, 2018 at 7:12 PM, Haribabu Kommi <kommi.harib...@gmail.com>
>> wrote:
>> >
>> > Update patch attached.
>>
>> + if (userid != 0 && dbid != 0 && queryid != 0)
>>
>> UINT64CONST() should be used for the constant for queryid?
>
>
> OK.
>
>>
>> It's rare case, but 0 can be assigned as valid queryid. Right?
>
>
> But for normal queries, in post parse analyze function, the queryID
> is calculated and it set to 1, in case if the calculation becomes 0.
> But for the utility statements, the calculation is done using the
> pgss_hash_string() function. I am not sure whether this function
> can return 0.
Though I've not read the whole code of pgss_hash_string(), ISTM that
the function can return 0. Otherwise, the following code is unnecessary
after queryid is assigned by hash_any_extended(),
in pgss_post_parse_analyze().
/*
* If we are unlucky enough to get a hash of zero, use 1 instead, to
* prevent confusion with the utility-statement case.
*/
if (query->queryId == UINT64CONST(0))
query->queryId = UINT64CONST(1);
> If yes, then we may need same handling to utility statements
> similar like normal statements but with queryID as 2 for utility statements.
That's possible, but I think that it's better to get rid of such corner
case at all.
Regards,
--
Fujii Masao
