Re: New function normal_rand_array function to contrib/tablefunc. - Mailing list pgsql-hackers

From Andy Fan
Subject Re: New function normal_rand_array function to contrib/tablefunc.
Date
Msg-id 87r0bswmv9.fsf@163.com
Whole thread Raw
In response to New function normal_rand_array function to contrib/tablefunc.  (Andy Fan <zhihuifan1213@163.com>)
List pgsql-hackers
Andy Fan <zhihuifan1213@163.com> writes:


(just noticed this reply is sent to Jim privately, re-sent it to
public.)

> Hi Jim,
>
>>
>> When either minval or maxval exceeds int4 the function cannot be
>> executed/found
>>
>> SELECT * FROM normal_rand_array(5, 10, 8, 42::bigint);
>>
>> ERROR:  function normal_rand_array(integer, integer, integer, bigint)
>> does not exist
>> LINE 1: SELECT * FROM normal_rand_array(5, 10, 8, 42::bigint);
>>                       ^
>> HINT:  No function matches the given name and argument types. You might
>> need to add explicit type casts.
>> ---
>>
>> SELECT * FROM normal_rand_array(5, 10, 8::bigint, 42);
>>
>> ERROR:  function normal_rand_array(integer, integer, bigint, integer)
>> does not exist
>> LINE 1: SELECT * FROM normal_rand_array(5, 10, 8::bigint, 42);
>>                       ^
>> HINT:  No function matches the given name and argument types. You might
>> need to add explicit type casts.
>> ---
>
>>
>> However, when both are int8 it works fine:
>
> I defined the function as below:
>
> postgres=# \df normal_rand_array
>                                         List of functions
>  Schema |       Name        | Result data type |           Argument data types            | Type
> --------+-------------------+------------------+------------------------------------------+------
>  public | normal_rand_array | SETOF anyarray   | integer, integer, anyelement, anyelement | func
> (1 row)
>
> so it is required that the 3nd and 4th argument should have the same
> data type, that's why your first 2 test case failed and the third one
> works.  and I also think we should not add a test case / document for
> this since the behavior of 'anyelement' system.
>

This issue can be fixed with the new API defined suggested by Dean.

>>
>> SELECT * FROM normal_rand_array(5, 10, 8::bigint, 42::bigint);
>>
>>                 normal_rand_array                 
>> --------------------------------------------------
>>  {29,38,31,10,23,39,9,32}
>>  {8,39,19,31,29,15,17,15,36,20,33,19}
>>  {15,18,42,19}
>>  {16,31,33,11,14,20,24,9,12,17,22,42,41,24,11,41}
>>  {15,11,36,8,28,37}
>> (5 rows)
>> ---
>>
>> Is it the expected behaviour?
>
> Yes, see the above statements.
>
>>
>> In some cases the function returns an empty array. Is it also expected?
>>
>> SELECT count(*)
>> FROM normal_rand_array(100000, 10, 8, 42) i
>> WHERE array_length(i,1) IS NULL;
>>
>>  count
>> -------
>>   4533
>> (1 row)
>
> Yes, by design I think it is a feature which could generate [] case
> which should be used a special case for testing, and at the
> implementation side, the [] means the length is 0 which is caused by I
> choose the 'len' by random [0 .. len * 2], so 0 is possible and doesn't
> confict with the declared behavior.
>
>> In both cases, perhaps mentioning these behaviors in the docs would
>> avoid some confusion.
>
> hmm, It doesn't take some big effort to add them, but I'm feeling that
> would make the document a bit of too verbose/detailed.
>
> Sorry for the late respone!

--
Best Regards
Andy Fan




pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: New function normal_rand_array function to contrib/tablefunc.
Next
From: Kisoon Kwon
Date:
Subject: Re: First draft of PG 17 release notes