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: